Interesting move by Canonical. Wonder if this is related to the new GUI for LXD that Canonical released recently? Or maybe they want to bring more projects in-house after the RHEL shakeup?

  • @[email protected]
    link
    fedilink
    English
    91 year ago

    How do you notice that you are not really awake yet? By thinking for several minutes about what LXD has to do with containers and then realising that you yourself had LXDE in mind.

  • @[email protected]
    link
    fedilink
    English
    21 year ago

    Used it once or twice then stopped, prefer raw lxc or even just manually creating namespaces if I want control.

    Never quite understood the point, the additional polish seemed fairly minimal from a utility pov.

    They should take over proxmox or something, give themselves a complete story.

    • @ikidd
      link
      English
      41 year ago

      deleted by creator

      • @[email protected]
        link
        fedilink
        English
        11 year ago

        I just switched off of proxmox back to vanilla lxc and virt-manager, I’m feeling brave right now :)

    • @[email protected]
      link
      fedilink
      English
      11 year ago

      I don’t know if I want a project as cool as Proxmox owned by the “you will use snap and you will like it” Canonical

    • @TCB13
      link
      English
      0
      edit-2
      1 year ago

      The point is that you want management, easy ways to create images, backups, move container between hosts, orchestration, network management and sometimes not only container but also virtual machines. LXD does it all very well and if you don’t want those resources you might as well use systemd-nspawn.

      They’ve taken over Proxmox. Not sure if you’re following but they have now a WebUI and the entire solution is magnitudes better than the crap Proxmox has been offering.

      • @ikidd
        link
        English
        1
        edit-2
        1 year ago

        Oh, bullshit. The minimal interface that Ubuntu offers isn’t even a pimple on the Proxmox front end, and doesn’t touch the filesystem, clustering abilities and backup solution that’s the equivalent of Veeam IMO.

        • @TCB13
          link
          English
          2
          edit-2
          1 year ago

          There you are, calling bullshit on my post while deleting your own where you clearly demonstrated close to no experience with LXD and its clustering capabilities. lol

          The minimal interface that Ubuntu offers

          Once again your ineptitude is palpable. Ubuntu doesn’t offer anything, the WebUI is a part of LXD.

          And yes LXD’s WebUI released “yesterday” is objectively better than Proxmox and it does touch storage and clustering.

      • @[email protected]
        link
        fedilink
        English
        11 year ago

        I haven’t been following, but that’s actually good to hear, proxmox needs a better ui.

        LXD, I suppose for the migration, but for any more complex orchestration I think you’ve moving to k8s or something more serious, LXD just has an odd “not enough but too much” feature set for me, I like things either push-button, or let me do it, this is kind of both.

        • @TCB13
          link
          English
          2
          edit-2
          1 year ago

          for any more complex orchestration I think you’ve moving to k8s or something more serious

          I guess it depends in your use case. If you’re taking about “regular” applications LXD/LXC might not be your best fit. LXD/LXC seem to very good for the more low level infraestruture related solutions. In contrast, whatever is typically deployed with k8s that is mostly immutable very reproducible and kind of runs at a very high level.

          LXD is more about what might power that “higher level” layer, more about mutable containers, virtual machines and very complex stacks that you can’t deploy with docker most of the time. As excepted people with those needs greatly leverage cloud-init and Ansible in order to get the reproducibility and the automated deployment capabilities that the Docker “crowd” usually likes.

          • @[email protected]
            link
            fedilink
            English
            11 year ago

            Ah, ok, understood then, it didn’t fit my use-case or workflow, it works for others, my bad, appreciate the correction!

            • @TCB13
              link
              English
              21 year ago

              Not a correction, it has its uses :) I would never deploy a web app and its API, database etc. using LXD, makes no sense, k8s is way better for that.

              • @[email protected]
                link
                fedilink
                English
                21 year ago

                I do that with lxd, but I have written ansible playbooks (almost like dockerfile? ) to automate the lxd containers. You could probably write some automation for scaling as well, but not something I’ve done, I have just opted for high availability with ceph & keepalived. Whatever works for your use case :) I do use some docker, but this is still nested inside lxd…

                • @TCB13
                  link
                  English
                  21 year ago

                  I also do playbooks to deploy stuff some stuff with LXD, but my end users only like Docker so, I kind of setup the infrastructure that allows them to deploy Docker on top of LXD containers that are deployed using Ansible.

  • ono
    link
    fedilink
    English
    21 year ago

    I wonder if this means LXC (which seems neglected lately) and LXD will soon be maintained by different people.