Stateful UIs and questions about LXD UI history

Incus
1

I gave github my phone number to post this comment so apologies if its not “fun”.

Why do you reject anything with a DB? Its so odd…

Say I wanted to implement “software BOM over time” would LXD/Incus accept that as MR/PR? or should it remain external? If it must remain external and I’m prepared to give it away why wouldn’t you want that? What about a “Search Index”? What about any other “fancy” feature?

It made sense at Cannonical but now, im so lost by this line. React is very “in” and “cool”, but we dont all like writing it. Unpaid it certainly would not be my first choice.

A DB lets a developer accelerate and expirment at their own pace, limiting it to PR/MR you’d accept (in GO), seems like it only hurts the project.

2

Hey there,

I don’t have any problem with web UIs that run their own database, use dynamic web pages, …
Something like Mosaic or lxconsole can definitely offer features that a stateless, static web UI that solely relies on the API can’t do.

But such projects also come with a lot more dependencies, whether it’s a more capable web server (to handle serving anything other than simple static files) or an external database.

My comment from earlier was in response to a question about whether lxconsole would work with the INCUS_UI env variable, and the response remains accurate that no, if you want to have a web UI that you can just drop into /opt/incus/ui/ and have it work out immediately, then your only options are those UIs that rely on static files and on no other external components.

Those more complex web interfaces will typically come with their own set of instructions on how to properly deploy them, what OS they support to run their daemon and database, how to setup the database for high-availability when in a cluster environment, how to perform backups of that data, …

2 Likes
3

Pff weak as fuck, and you know it. The only code LXD code got as extension was paid for - that should speak volumes.

Someone might write something just to impress you, but know they wrote it simply for that purpose.

Years sunk into these web UI-s and you blow them off because they dont fit some ENV variable made after them? Fuck that - waste of a phone number.

I didn’t spend 10 years at Canonical but its clear the devs have.

4

I really don’t understand what you’re unhappy about.

You can very easily package Mosaic or any other of the more complex web UIs and have that package drop a single file in /opt/incus/ui/ which performs a redirect to your web server.

As I said above, this obviously needs more work than a stateless web UI as you can’t just unpack a tarball in /opt/incus/ui and call it done, you do need to install additional packages which may or may not exist (in the correct version) on the system that you’re installing this on, but that’s something you can absolutely handle within your packaging.

I think our approach is very reasonable in that as an upstream project, we don’t provide any official web UI, we’re not web developers and there are many good options out there.

To make it easier for those building web UIs, we do have a tiny bit of code which makes it so anyone hitting the Incus HTTPS endpoint with a web browser is served whatever is in /opt/incus/ui (or whatever INCUS_UI points to). This is served through Go’s basic HTTP server so all this can do is serve static files. For stateless web UIs, that’s enough for everything they need, for stateful web UIs, you can drop an index.html in that path which then redirects to wherever your own web server is running.

This makes it so whatever the web UI that’s in use, stateless or stateful, the user can just go hit the Incus HTTPS endpoint and get the UI to come up.

3 Likes
5

@turtle0x1 I would also kindly request that you go read the code of conduct for this community again at https://discuss.linuxcontainers.org/faq

2 Likes
6

Ya know you asked LXDMosaic to be the UI … you really asking me justify this?

Man I dont care but what a waste of effort, do whatever you like.

I guess just dont trust the words you say huh?

7

Let’s be clear on what happened here :slight_smile:

Back in the LXD days, we were tasked to build an Ubuntu Core appliance image, this came with no web UI which seemed a shame and so I tried to change that by having us include LXD Mosaic.
You and I had a bunch of back and forth about that, resulting in a snap of LXD Mosaic and some good progress towards getting that appliance up and running.

Then Canonical basically killed (or stopped caring, not sure which) about those appliance images which ended up wasting both of our time on this initiative. I believe we only ever saw 2-digits usage on those prebuilt images :frowning:

Later on, as part of trying to compete more with Proxmox and VMWare, Canonical decided that they wanted their own web UI for LXD, following the design patterns and look of their existing products (Anbox and MAAS). I was generally supportive of the idea but did repeatedly raise the point that we have an active community of web UI developers and that while the company requirements likely meant we’d end up with a new project rather than being able to just ship one of the existing ones, that we should make sure to try and hire or contract some of the community folks, make sure the job openings are widely shared across the community and that code, roadmap, … should all be handled in public.

As you no doubt noticed, that last part didn’t happen. The LXD UI efforts were moved outside of the LXD team control and onto the general web & design team at Canonical which is responsible for work across all web interfaces and websites.

While I personally like the folks who have come to work on the Canonical LXD UI, I still strongly feel that having that team be completely outside of the control of the LXD team, especially when it comes to job openings and hiring, was a big mistake from a community standpoint.

But there was really nothing much I could do about this situation, other than keep complaining about it, which I’ve been doing until the day I left the company.

Now when came the time to talk web UI with Incus, our decision to just ship the basic web infrastructure to serve web UI files to users but nothing else, specifically came from not wanting a repeat of the mess that happened with LXD. The current solution offers a level playing field for all possible Incus UI, making it easy for them to provide packages that will nicely integrate with Incus.

As Incus itself doesn’t do any packaging (we only release code tarballs), whether to package and ship a UI by default becomes a distro decision. Some will just ship Incus on its own, some will package some of the possible web UIs and some may have one of those ship by default with Incus. That ultimately isn’t the Incus’ project concern. This will mostly be reflected in us not providing UI instructions in our documentation unlike what LXD is doing these days.

1 Like
8

It is what is big man, you say it you get it.

Aslong as it what you say it is others will go along :smile:

Ill be sure to join a large org to fuck others over inbtween. 3 year pissed away - i wouldnt recomend writing anything for LXD/Incus if you fucking had to.

Sorry for wasting your time, ban me under code of conflict - I really couldn’t care less. Aslong as others know what they are working towards.

11

I have moved this thread to its own topic to keep the original topic compliant with the CoC.

Big orgs come with a lot of different business requirements and questionable decisions, that’s unfortunately a fact of life…

The LXD UI situation as described above is certainly a good example of how business requirements and decisions made by upper management can lead to very disappointing decisions and alienation of the community.

The same can be said of Canonical’s decision to take LXD away from the Linux Containers community and to remove all non-employees as maintainers.

At the end of the day, there’s little more that I can do about either than resign and try to help run a properly open source project with maintainers from across the industry (some employed, some not) and try to better define things to avoid repeating the same mistakes that happened under Canonical.

2 Likes
12

Yah yah hide beind the code of conflict, sorry your decisions require beeing challenged :smile:

Why would I, the longe test term independent web-UI maintainer care about an agreement I dont have?

I can post your messages where you said you wanted LXDMosaic to be your choice, n you bailing on that.

All I wanted was you to explain the “DB less” decision, the rest is on you (the new one is almost better than mine that still works - I dont care about the specifics of mine I care about the general tone).

13

Yes, back in 2020 when we were building the Ubuntu Core appliance as described above, I did want LXDMosaic to be what we’d use for the web UI. You did a bunch of work to get a snap up and running, I did a bunch of work to get that all integrated smoothly and then the initiative just went nowhere, I suspect to this day there’s probably still that appliance waiting in a review queue somewhere as Canonical hasn’t been publishing new Ubuntu Core appliances in a long time, nor maintained their existing ones…

What I described to you at the time was:

So that’s the bare appliance, then we’d like to have a second appliance image for LXD mosaic. Effectively containing the exact same thing as the LXD appliance but also having LXD mosaic installed as a snap in the image and pre-configured so the user can just hit the appliance with their web browser from another system on the network and immediately get going.

And I stand by the fact that this would have made a very good appliance, very similar experience to a Proxmox type thing but with an easier installation method, easy to run on Raspberry Pi and the like.

But then the whole appliance thing got silently de-prioritized/dropped and it took a couple of years until Canonical management decided that having a UI became a product need and so started hiring into the Canonical web team as I described in previous posts.

2 Likes
14

So you have no excuse? You wasted both our time for no reason (focus on both our time)

So you agree Canonical owe me £100K in salary and frustration with SNAP?

A huge waste of both our time, and now your stick to to line?

I hope nobody waste their time writing a web-UI while Incus sticks with this waste of time attitude.

15

Sorry, I don’t understand that you have
you easily create redirect page to your solution and make it compatible with both LXD and Incus

2 Likes
16

something like DEB or RPM page that setup everything will be your going to solution

1 Like
17

@turtle0x1
Looks you don’t understand why Incus does not accept an UI with database, and @stgraber looks you did not explain it well, although it’s obvious like a common sense to me, so @stgraber let’s me explain the “DB less” decision here, if anything wrong please let me know.

The key reason is LXD is designed a cloud running on edge. Like any software running on edge, it must be running without maintenence or with less maintenance as less as possible or say, to be cattle app. Look at LXD itself design, it’s using dqlite(or cowsql/cowsql: Embeddable, replicated and fault tolerant SQL engine) as its database engine. As you know, sql databases are classic pets app instead of cattle one. But cowsql has changed itself from pets to cattle. So that cowsql has been accepted by incus to be the database without incus being changed to pets. So the DB less decision explaination is, incus wants to keep itself cattle app since it’s as a cloud running on edge, and include an UI with DB would make incus a pets app.

18

I think a web ui should take a global approach, rather aiming to follow lxd/incus closely and try to implement blindly every single feature, some of which proven to be politically motivated, aim to promote something else like Maas, Snap, Juju, GiGi …and will be rendered useless depends on governing party.

Canonical is subordinated to AWS and alike, LXD was subordinated to Canonical, now no one need another web UI fully sub-subordinated to LXD / Incus.
An Independent approach like proxmox, seeing the global use case with focus on business and hosting critical need and less a blind follower of LXD will save future disappointments and loss of thousands hour development to some internal power grab.

19

Someone might write something just to impress you, but know they wrote it simply for that purpose.

I have been writing a cloud infrastructure panel since 2020 (Hye Ararat). I have visited a variety of technologies over the years, and ultimately Incus (formerly using LXD) has stuck. To say that the people writing UIs that utilize Incus is simply to impress stgraber is preposterous, and I actually take personal offense to that as it undermines the motivation of the work that me and my team have put forth over the last several years with literally nothing in return. People write stuff on Incus because it is the best at what it does, and I am very thankful for stgraber’s continued leadership on the project so it can continue to be the best at just that.

2 Likes
20

A few comments here reveal a recognisable trend in tech businesses — a movement from primarily open source software with paid support towards proprietary licensable software and service platforms.

Add venture and investor demands and interests that focus on growth and scale, for the sole purpose of making money for investors, and we get products designed around these demands.

Sometimes there is balance between the interests of investors, business, employees (to build awesome shit that fulfill a wide range of use cases) and customers — some who want to build their own platforms and some who want products that scale into turnkey platforms.

Canonical seems to have less and less balance and is primarily serving investors. But other strange influences seem to be at work which presents as baffling and incomprehensible.

Incus is free of all that BS and can develop to fulfill all manner of goals and use cases.

One use case I am interested in is running it on Vmware’s Photon OS, on ESXi and Vsphere. No doubt Broadcom, which has a reputation for an incredibly unbalanced investor focus, will not like Incus running nicely inside Photon OS running containers they can’t get licensed fees for.

Does Incus need a UI to help it shine? Definitely. But fostering innovation with excellent APIs and even SDKs is a great strategy. But, there is always the danger that some corporation will build an awesome web UI platform that pushes out everyone else and leads to the investor focused non-sense most of the open source world abhors.

1 Like