Oh sorry. I thought that would be better than sending a bunch of screenshots. You can see more about it at https://hyeararat.com. I’d be happy to message you screenshots/features privately if you want them but they just take too much space in the Incus thread.
Is your code modular?
I believe it would be beneficial for us to avoid duplicating existing functionality. One possible solution could be to fork LXD-UI and incorporate it into the Incus codebase. This approach may provide us with sufficient capabilities, allowing us to proceed with our development independently or ensuring synchronization with LXD-UI.
Great work man, keep up the good work.
Personally I’m going to, essentially, recreate the ESXi/ Proxmox UI because so many people are already familiar with that and transitioning would be super easy then, trust me I’ve worked with these people and so many will not budge simply because a button “used to be on the right side now it’s on the left side”.
I’m afraid I have to strongly disagree with on two fronts. 1- incorporating the frontend code into the same co-debase as the backend is a terrible idea that will ruin the developer experience and make it much harder for new people take interest in the project. Essentially we’ll end up with people who will take one look at the repo realise it’s gonna take a whole bunch of time to make heads and tails of the code and move on, every little help counts!. 2- canonical/ubuntu has a specific design language that can be seen in LXD UI and this is would again be bad idea to reuse their design, there’s no point in taking the front end code and re-theming it when we can spend a couple of weeks building a new one for this new project.
In conclusion:
- UX (User Experience): should be optimised for a large portion of the existing IT professionals that are already sworn to the likes of Proxmox/ESXi
- DX (Developer Experience): the code should be broken up into smaller, more manageable chunks so that it’s easier on small time contributors, cause it’s not easy to get people to contribute to something they’re not getting paid to spend time on understanding. Packagers/Distribution will have to take care of putting all these parts together (or not) depending on their standards and rules not the developers. I would argue that the lxc command line util should be in its own separate repo.
1 Like
I’m not sure what you mean by modular, but it is very easy to add pages to because it communicates directly with LXD rather than going through a second backend that one would have to maintain.
I’ve been thinking about this and it seems like no matter what UI is bundled people are going to be unhappy because they have different preferences. I think it would be best if no UI were officially bundled, but rather left to the community. Users can choose what UI they would like to install, and to make different UIs easier to find, there can be a section in the documentation linking to all the major UIs available.
Define “major UIs” in a manner that doesn’t rely on tracking the number of active users, since most people do not like tracking and will disable such and is therefore an unreliable metric.
Just like if someone makes a functional UI that’s noteworthy it can be listed, kind of like how they did with LXD API wrappers
“Noteworthy” is just as ambiguous as “major” and you missed the point. Never mind.
No not never mind. Why are you so passive aggressive to me? I never did anything to you and you call my stuff terrible and keep going with these attacks. It’s quite obvious that I am stating anyone who makes a usable functional UI should be listed, but you seem more interested in making some sort of problem or argument out of it which I really don’t want to have. I am just trying to find a solution that would make everybody be able to have the UI that they are happy with by giving them choices, but the way your talking has some sort of innuendo associated with it that insinuates that I have some sort of other agenda, which I really don’t appreciate and don’t have.
1 Like
It has absolutely nothing to do with you. Don’t take it personally every time someone disagrees with you or points something out in what you’ve said that might warrant some more consideration.
It becomes personal when your downright rude and say “that’s a terrible video”. That’s really not a necessary comment. You could have said something like “I wasn’t really able to see much of the UI in that video because the pacing was too quick, could you show me some images of it?” and that would’ve been great. I don’t really want to have an argument with you I’m just saying I’d rather have polite and productive conversations than ones like these that make everybody feel like trash.
3 Likes
Aah the wind of war!
3 Likes
Very nice, I’m very happy to hear this. 
Regards.
2 Likes
This is amazing news! How wonderful, congrats to the Incus team for getting “the band” back together! Looking forward to this next chapter in the Linux Containers story.
3 Likes
Thank you very much, the team, for introducing Incus. I was losing hope on lxd after Canonical anon cement. Looking forward to seeing terraform and Ansible and also the interesting external scheduler work (starlek and so on).
Would it make sense to have community live QA regularly? Something people can show and present if interesting and create more momentum for community work. I would contribute from HPC side.
Been an LXD contributor before, would be nice if there is some place to contribute in new project and become a part of the team.
1 Like
Great news for the community! It’s always good to have this project alongside a ‘commercial’ product/project.
I do hope that the people who were active here can contribute in the future, like @tomp. Of course I don’t know what happened. But I am also grateful to him for his great effort.
This is the time for a fresh start & project for the community. Thanks Aleksa and the team!
They are certainly most welcome to contribute directly to Incus, whether Canonical will let them, at least during work time, is another question 
3 Likes
LXD project never was community driven.
It was the core team leader living his visions and sometimes making sacrifices to satisfy Canonical Agenda, such as forcing users to implement and use otherwise failed projects like snap as well as serving requests of largest Ubuntu client AWS.
So, I think it is safer to be totally at canonical, pumping it with their agenda, without facing resistance.
As for Incus, it starts with it’s name, which the community perhaps barely would agree with, minor changes advertised as revolutionary.
What exactly is community-driven there?
Open Source projects do tend to need some kind of leadership, you can’t put every single change to the vote. Usually the way this works is that those who contribute the most become maintainers and those maintainers then have the rights to decide what goes in and what doesn’t. This typically makes sense as the maintainers are also those who have to deal with the long term maintenance consequences of those decisions.
For LXD, the maintainers prior to Canonical taking the project over were:
- Christian Brauner
- Serge Hallyn
- Tycho Andersen
- Free Ekanayaka
- Thomas Parrott
- Myself
Of those, only Tom and myself were working for Canonical.
I was acting as project leader, handling most of the communication around LXD while Tom was focusing more on support and day to day operations of LXD and the rest were contributing less often but still aware of any major changes coming in.
Following Canonical’s take over of LXD, as far as I know, the project now only has a single maintainer, Thomas Parrott…
Incus gets us back to having multiple maintainers from a variety of companies with the list currently being:
- Aleksa Sarai
- Christian Brauner
- Serge Hallyn
- Tycho Andersen
- Free Ekanayaka
- Myself
I’m the one currently investing the most time into Incus, the reason for that being pretty simple, I’m self-employed and can afford it, most of the others have day jobs that take a significant amount of their time 
That being said, we talk to each other daily and have all changes cross-reviewed, we also have a number of contributors who are tackling some of the initial pieces of work on Incus.
Anyway, we’re not advertising Incus as revolutionary, it’s a fork of LXD, it’s that simple.
We will use the opportunity to get rid of a bunch of stuff that was annoying to maintain and otherwise mostly unused and we will in time get to add new features which may or may not get picked by LXD.
This is going to take time and we’re likely another couple of months away from having an initial stable release of Incus that people can actually consider.
If you’re happy with LXD and where it’s headed, that’s perfectly fine, you can stick with it. There’s no indication that Canonical is reducing its investment in it and Tom is still over there keeping things going.
7 Likes