Hye Ararat Beta 4 is now available

Incus
,
1

Howdy everyone,

Hye Ararat Beta 4 is now available. The release is available here: Release Hye Ararat v3.0.0 Beta 4 · hyecompany/ararat-web · GitHub

For context to those new: Ararat is a modern web interface native to Incus currently in development. You can learn more here: Introducing Hye Ararat: A Web UI native to Incus , and installation instructions are available on our GitHub.

In the Beta 3 announcement, I stated that Beta 4 would introduce storage pools as our first primitive beyond instances. After a community member did some experimentation with authorization and reported several issues, I found some large changes would need to be made to support that in the future. I decided that rather than pushing storage pools through now, it would be better to harden the foundation & delay storage pools to Beta 5. You can read more here: Hye Ararat Beta 3 is now available - #4 by Hye-Dev

Some new information: since Beta 5 will already present a large refactor, I’ve decided to also go after some other areas that have been on my mind. Most notably, Ararat will no longer be built on Next.JS, and will be moving to a Vite stack. This is more compatible with the SPA + client-side nature of Ararat. These changes are well underway on my local machine, and will be on the repo in the coming days.

Thank y’all for the continued testing & feedback! These decisions would have never been made without y’all. As I said in Ararat’s introduction post, the community-driven nature of Incus is what makes it the best, and it’s absolutely amazing to already see this transformation in Ararat at such an early stage.

These architectural changes are not present in this release and will debut in Beta 5 alongside storage pools. That being said, Beta 4 still made significant progress that warrants some announcement & excitement!

What’s New

New File Manager

image
image3578×2054 320 KB

The file manager now includes:

  • Dedicated search tool
  • Directory count
  • Persistent go to (ctrl/cmd + k as well!) / path copy actions

The file manager is now also significantly faster, taking advantage of the new caching system introduced in Beta 3 last week (see Hye Ararat Beta 3 is now available ). It also now actually informs you when a directory is empty, rather than just showing a generic blank screen! (groundbreaking I know!)

image
image2874×798 98.7 KB

The file editor has also received various improvements, now featuring a theme consistent with the rest of the interface:

image
image2868×1338 118 KB

I also have expanded the syntax highlighting support, now also supporting C, C++, and Go.

Ararat also now automatically detects what files can be opened in the editor, and what must be downloaded by automatically inspecting the file for binary data before deciding to open. Any text files just open seamlessly, and everything else downloads straight to the disk.

New Instance Tab Design & View Transitions

The new caching system introduced in Beta 3 made data appear pretty much instantaneously, removing the display of a loading spinner most of the time.

Usually, a loading spinner serves as the natural transition between pages, however, after Beta 3, data just appeared immediately, which didn’t feel quite natural, so I’ve employed view transitions across the instance interface to bring back the natural fluid feel Ararat previous gave.

You can also see the instance tabs have been redesigned, they just didn’t feel quite right before. I hope y’all like them, these will be re-used across other primitives.

Additional Notable Changes

Instance logs have been moved to their own dedicated tab, rather than within the instance management dialog. The visual mode is also now properly virtualized, so a 20K line file will no longer lag out your computer!

Several of you reported a bug where Ararat reported that the “path” parameter was required, preventing the attachment of non-filesystem storage volumes. This has been fixed. You can now attach your non-filesystem volumes with no artificial blockers.

2

Side note:

I’m aware of some issues introduced by the data fetching layer re-write back in Beta 3. While this release did address some of those, there are still some present.

For example, the instance table may not properly detect its stale from the cache unless a change is made while Ararat is open, and CPU usage calculation always outputs 0%. These are all caching issues that will be addressed early-on in Beta 5’s development.

The reason I note this is data fetching is used literally everywhere, and Beta 5 is Ararat’s monthly “large” release, so it leaves the normal weekly cadence for a release date of May 24th, which is a little far out for something that can get pretty annoying.

Usually, I would merge the same fix for an issue like this from the bleeding edge into the active beta channel, however, since Beta 5 is structurally different, the fix does not overlap at all (the layer was effectively re-written again). Therefore, I recommend for the most stable experience, actually sticking to the bleeding edge builds until then. You can think of this as a using Windows Vista vs. Windows 7 Beta situation. Apologies!

3

Hey everyone,

Unfortunately, Beta 5 will not be launching today.

I’ve been hard at work on the refactor announced both here and on my response on Beta 3 Hye Ararat Beta 3 is now available - #4 by Hye-Dev . This included both a complete re-write of the Incus communication / caching layer (again!), and a transition of the entire stack from Next.js to Vite. These are fundamental structural changes, so these are much more carefully thought out, with much less AI involvement (next to none). This has been a much larger than originally anticipated endeavor, and in the process I have discovered a lot of technical debt that I feel the need to address (some of which arguably contributed by the aforementioned AI involvement, thinking we need some sort of policy on this, would love to talk about that). As a result, I am going to have to ask for your understanding in a divergence from our regular beta release cadence. I could absolutely just push through new features and primitives like the storage pools I have continuously promised (so sorry!) on the current foundation, however, the quality of the user experience comes first. To put it plainly, Ararat should have a foundation that lives up to its namesake, even if it comes at cost of velocity.

I am deeply sorry for establishing such unrealistic expectations in relation to Ararat’s velocity. It was my genuine belief and intention to deliver on the roadmap I outlined. The responsibility of establishing & communicating a realistic roadmap with the community lies with me. I can’t make any promises as to when Beta 5 will release, or what will be present within it. That being said, I can provide an update on where things stand.

Some technical details as to where progress as stands:

Things are on my local machine for now. This is just going to be several giant commits when done (e.g. movement to Vite + Data fetching is going to be one). I can’t really push incrementally on this one because it’s basically a re-write using the same components, everything has to be moved to work, and many shared areas have behavioral changes as a result of the new data fetching system. This is why the GitHub has been quiet.

Data Fetching

The new data fetching system is pretty much done. It’s now essentially a replica of the Incus database living in your browser, populated into memory for fast access with a write-back cache, automatically handling relations and intelligently inferring resource existence through any hints dropped by events or metadata (e.g., a used_by on a project fetch would immediately inform Ararat that those resources existed if it didn’t know). Beta 3’s was already extremely good at this sort of thing, but this new system knocks it out of the park. Sometimes, even the first load of a resource won’t even have a loading screen because of this smart inference! Feels like sorcery, not even exaggerating there.

Migration

The Vite migration is still in progress (the above is in Vite already!). Most of the technical debt discovered lies in the larger re-used individual components, like the general configurator. This work is almost complete. I am exploring whether or not I should PR some normalization now into Incus on some of the endpoints we use and write for those new structures, or keep the methods we currently use (which in some cases even resorts to hilariously clever description parsing) before finalizing. I think this will depend on how much of a pain this becomes when implementing future primitives. Community collaboration on that would yield really positive results. Migration of the base primitives themselves (e.g. projects, instances) has started, but is very early.

I’ve been having a little bit of a battle with, of all things, getting the view transitions to work properly. Next.js used React canary, so I could use the experimental view transitions API. I instinctively thought it better to use React stable, so I’ve been making my own lightweight view transitions adapter to handle this. Moving to React canary would make this a lot easier. I’m 50/50 on this decision. Would love community input.

In terms of migration, anything I didn’t mention has been a breeze to move, so wasn’t notable.

New Primitives/Features

There is no progress on new features or new primitives such as storage pools. All my efforts are focused on the foundation.

Establishing Future Expectations:

Some may question why all of the delay and turbulence in the development process for an “Incus UI”, seems pretty straightforward, right? That’s understandable on a surface level, but this generalization is exactly what Ararat seeks to challenge. Ararat is actually much more complex than meets the eye. As stated in its introduction post, I specifically designed it not to be a simple representation of the Incus API in Web UI form, but rather a fully fledged first class interface, feeling just as native to the browser as the CLI does to the terminal, for any user of any experience level to feel comfortable in. Ararat’s development process is not directly comparable to something like incus-ui-canonical, there’s a lot more engineering to it. You can see this already in the past few updates, building a SPICE client from scratch, bringing you graphical performance faster than you even thought was possible in the browser. Our normalized caching / data fetching system which keeps network traffic to your Incus host minimal, while also eliminating almost all loading screens & making the interface update live as changes happen on the server. Ararat even went as far as featuring automated binary file detection in the browser, just to make editing a little easier. Almost every single little detail I add, is implemented to this degree of thought in relation to the user experience, regardless of the level of effort or how small it seems. This is the reason why Ararat exists in the first place. I fell into the trap of planning deadlines & our roadmap around the velocity of building something with an API-wrapper degree of simplicity, when Ararat is uniquely “API-native” (if that’s a term). Going forwards I will be much better about this.

As for the original July 24th target for stable release with all primitives, I believe that this is still in the cards, provided there are no further surprise technical debt situations. I actually intentionally set that date with a 1 month buffer from what I anticipated.

I hope y’all will continue to provide feedback! This entire refactor started from one message from a single community member. I hope that makes it clear without a doubt, that your voice has huge impact.

4

I would like to thank you for an update and your effort with developing Hye Ararat project. I believe modern UI is a missing piece of the entire Incus stack. Since Stephane and the Team are focused mostly on functional level of the project, UI and worklow orchestration was missed from my perspective. To be considered as alternative to other hypervisors for masses, Incus must have user friendly, properly designed UI. This is already happening for Proxmox (PegaProx or Proxcenter) and it was a core for VMware success.

From my perspective you should take as much time as possible to develop well designed, fast and secure product. I really appreciate your updates on Incus community forum.

The only part I’m worried about is that Hye Ararat is a single person project (at least for now). If you will lose your energy or passion with developing it, there will be no one else who will support it. Take a look on LXConsole project. This is a great tool but updated very rarely in recent months. Unfortunately I’m not a developer so I cannot participate with developing Hye Ararat, but to let you know I really appreciate your work on this.

1 Like
5

Most great ideas start as one persons passion - “1 dev” - its not a reason to write it off, ever.

The only UI with > 1 regular dev im aware of is lxd-ui, and I suspect that’s only supported by cash from unrelated sources - not buy support contracts for LXD directly (maybe its directly funded, but I have my doubts).

Cash/crypto > contribution > helpful feedback > literally anything else > “why only 1 dev" comments

Estimates are the hardest part of software dev - with or without AI - good luck on the next release.

6

@Daniel1 Completely agree on every point, and appreciate the kind words!

On the solo development aspect, I also completely agree, and this is the reason why I actually don’t want Ararat to be driven by me. Ararat should be driven by this community, ideally with governance by Incus leaders & myself. Close collaboration would definitely make this much more apart of the “stack”. I also believe this approach is what would differentiate Ararat’s lifespan (for lack of a better word) from that of those which came before it. The passion driving the project would not be controlled by the flame of one (which is very bright! I love working on Ararat), but that of the entire community.

The most valuable contribution by far is feedback, and yours has given me a lot to think about in terms of governance & longevity :slight_smile:

7

I’ve been watching all the progress and providing input where possible to try and steer it towards something we could turn into an official Incus UI.

So far it’s hit my main requirements:

  • Compatible license
  • Not based on the existing LXD UI (would be a licensing issue)
  • Limits hardcoded logic as much as possible, instead relies on data made available by the Incus daemon
  • Javascript-only client, no server component, Incus is the stateful server

My plan is to let @Hye-Dev keep pushing for end of July stable target, then have a discussion with the Incus maintainers on accepting it as the future “official” Incus UI, at which point we’d look at getting it fully integrated with the project, get more folks involved with development, figure out what needs to be implemented before we can start phasing out the LXD UI fork, …

So definitely something to look forward to in the coming months!

8 Likes
8

I’m impressed by the progress you’ve made! I just replaced the Canonical UI with yours and everything works as expected, including OIDC!

It’s missing some features, but that’s expected for a Beta. Are there contribution guidelines and a roadmap available? I’d love to get involved!

1 Like
9

Thank you! Glad to hear things are working as expected.

Unfortunately, contributing is a little complicated right now. There is an ongoing comprehensive local “re-write” (not sure what to call it) from Next.JS to Vite (hence the lower GitHub activity as of recent). This has morphed from much more than a stack transition, as in addition to a ton of underlying logic changes I posted about last week, I am also implementing a bunch of new enhancements into some of the existing components (eg. the configurable options selector now groups related options together to appear as “one” & features rich icons and descriptions). As the structure of the codebase will be completely different, I can’t currently merge any contributions.

Right now the contribution guidelines are pretty lax ( GitHub - hyecompany/ararat-web: Take your infrastructure to its peak · GitHub ), requiring just DCO sign-off, however, past AI-use did introduce some technical debt, so I am considering introducing rules around AI-use on contributions impacting core shared components/utilities when the new base is released.

Before the “re-write”, I utilized our GitHub milestones to outline a roadmap ( Milestones · hyecompany/ararat-web · GitHub ) and released on a regular cadence, however, this is now out of date because of the “re-write”. This will be updated when the new base is ready. That being said, I still fully expect Ararat to have a stable release with full primitive implementation towards the end of July. I don’t have an ETA just yet on when the new base will be published.

The changes I’ve made make implementing new primitives substantially easier, as much more of the logic is shared. Hopefully this will also make contributing much more straightforward!

1 Like