24.10-RC1 - Delay to 10/2

[kris]

@p0358

big one: no way to edit your app after it was created!!! it just says “Error detected reading App” in the interface

This is noted and resolved in the .0

@p0358

no way of specifying ENV vars, it’s common for apps to require a .env file, and no, it doesn’t seem env_file: on all containers works properly (expanding vars in mounts seems broken, plus it’s annoying to copy-paste it to every container section); there could be an input section for ENV file contents under Compose section if nothing else

This one is tougher, not sure yet when / how we might expose it. Almost better to run docker compose from the CLI to handle that use-case. Maybe down the road though…

@p0358

no way of specifying “base dir” for Compose, often they expect us to link files by relative paths there. That’s not a huge one as this can be adjusted, but still

Yea, annoying, we’ll have to see if there is a way to accommodate that down the road.

@p0358

minor: after adding new app, it doesn’t appear in the Apps screen before refreshing the page or changing the tab in the dashboard to something else and back to Apps

Known issue, expected fixed in .0

[p0358]

Thanks for the response.

@kris

This one is tougher, not sure yet when / how we might expose it. Almost better to run docker compose from the CLI to handle that use-case. Maybe down the road though…

I’m led to believe that it could be accomodated with --env-file option like docker compose --env-file ./config/.env.dev up. This way perhaps it’d be enough to just place the contents of supposed “env file” input field into some file and provide it like this? If this worked, that’d probably be the least burdensome way.

I could end up running docker compose in CLI in worst case, I think it shouldn’t break anything/conflict intuitively. But I presume there’s that con that it won’t be visible in the UI then, so not ideal either…

Speaking of UI, I remembered one more thing now:

In this size of layout (1920x1080 screen, maximized Firefox with sidebar on the side, in this case for Sidebery extension for vertical tabs), the list of applications gets cut off and a slider appears, concealing part of update status and the buttons to stop the apps, which didn’t happen in the older version (possibly due to less columns previously).

I don’t seem to have this issue on my 16:10 monitor, only 16:9 (on 16:10 the right-side app info is in one column instead of two). I believe it could be improved to fall back to that more aggressively if the main apps pane was to be cut off from usability perspective. After all I think all apps’ info table is meant so that their properties are all visible at a glance.

By the way there doesn’t seem to be an explicit Stop button after clicking the app elsewhere in the interface (anymore? iirc). Which could make some sense if the stop button in the table was meant to be a singular way of stopping/starting an app, but then even more-so it shouldn’t be concealed by default I think… (due to that I was instinctively looking for some Stop button on the right-side panes instead)

---

Another tiny thing: will there be some way of specifying URL/path to custom image for custom apps just for some eye candy so it’s not blank? Could be just another input field on the custom app template.

And speaking of templates, the “Custom Config” field could have an example placeholder of some super-basic Compose contents by default, as I saw someone on the forums confused about whether to put services: at the top or not, just an idea.

[sfatula]

I posted a potential (tempporary maybe) way to get around the env file and dockerfile issue, and even the inability to edit here:

Electric Eel - How I am using Dockerfile, .env files, compose files

So, an earlier discussion noted the limitations of Eel regarding not being able to edit after uploading them via create custom app, inability to use .env files, and, needing to keep Dockerfiles elsewhere via a full path build context. I have solved all that, for the way I want to do it at least. Let’s see if anyone likes. Here is a caddy reverse proxy setup with custom plugins (porkbun dns and labels) where I illustrate: Dockerfile: FROM caddy:2.8-builder AS builder RUN xcaddy build \ --wit…

[p0358]

Another issue whereas I’m not sure if it’s something that’d be classified as a bug.

If you deploy a compose, and one of the apps keeps exiting (due to any problem that just causes it to die) (plus possibly some container in Starting state due to waiting for it), it’s impossible to stop it, the STOP button is grayed out:

Now of course once editing the app and its Compose file is fixed, I presume we could just go to Edit and Save without changes, which is why in the end this might not be a huge problem and iX might opt to keep Stop grayed out during deployment to avoid various bugs/quirks/race conditions if potentially two commands are ran at once to start and stop stuff.

At the same time it feels like the ability to stop the apps to fix whatever issues arose without having to do an operation on living organism would be beneficial, but only if it could be implemented safely.

(right now the only “safe” way of getting myself out of this stuck situation seemed to be to remove and re-create the whole app lol)

[DjP-iX]

This is fixed in 24.10.0

[p0358]

Neat, the iX team is really ahead on this release, love to see it.

I noticed one other tiny issue and submitted a PR to GitHub.

But now noticed yet another one that I’m not sure of easy fix (by glancing at code I think it’s not fixed yet, since blame shows it wasn’t touched for 2 months I think):

App update tooltip shows the current app version as “available” for update (actual latest is 2024.10.0 in this case), after detecting an update. As I understand it comes from interface AppMetadata in code which is supposed to probably contain current information about latest version of the app presumably (from charts?).

In this case it’s all from official apps and clicking Update button brings up a dialog with checkbox that has correct actual latest version filled in, so it’s just the tooltip that’s wrong.

Also with this implementation this makes me wonder if we’ll get update available notifications for custom Compose apps at all. And if not how would we update them, just periodically clicking Edit and Save?

[p0358]

Another random and maybe non-reproducible bug:

All apps in catalogue showed as Installed (despite not being true), opening Apps in another web browser tab or clicking on category expansion immediately fixed it. Seems to have happened randomly, not sure if me installing a new app in another tab could had triggered it?

[sfatula]

You just go in the shell and docker stop it. You’ll see the app return backed to a stop state in the UI.

[DjP-iX]

@p0358

Also with this implementation this makes me wonder if we’ll get update available notifications for custom Compose apps at all.

I’ve been told that custom apps should monitor for upstream updates at to the image and use the same update process as catalog apps, but haven’t tested it myself yet.

A bug report for the update version would be helpful. That’s a good catch.

Don’t know about the Installed issue. Unless its reproducible I don’t think there is much we can do about it. I haven’t seen or heard of that happening before.

[p0358]

@sfatula

You just go in the shell and docker stop it. You’ll see the app return backed to a stop state in the UI.

Hm, if that won’t mess things up. Thing is, with multiple containers that are co-dependent I was a bit spooked about potential order at which things should be stopped. Since I don’t seem to be able to use “docker compose” commands even if entering the dir where the generated compose file is at. I guess doing explicit stop on container IDs will also prevent them from being tried to be started up again automatically after failure (I mean that’s the intent, instead of fighting with the daemon)?

Just trying to ensure if you tested that’s fine with multi-container apps in this kind of state, as it might be different from stopping a single container app from fully Started state to stopped.

@DjP-iX

I’ve been told that custom apps should monitor for upstream updates at to the image and use the same update process as catalog apps, but haven’t tested it myself yet.

Fair, I’ll be on the lookout if a tooltip will appear for any of them then (considering single- and multi-container ones).

@DjP-iX

A bug report for the update version would be helpful. That’s a good catch.

Okay reported it at: [NAS-131747] - iXsystems TrueNAS Jira

@DjP-iX

Don’t know about the Installed issue. Unless its reproducible I don’t think there is much we can do about it. I haven’t seen or heard of that happening before.

Actually it just happened again. So if you wanna try reproducing, do this when you have some leisure time and a running TrueNAS system that you won’t be actively using for a few moments as far as the UI goes:

• open one tab to Apps → Discover Apps and keep it on the main Discover screen
• open second tab to Apps where you have a list of running apps (I guess have at least one running)
• I also had a third tab opened to system shell

Just keep them opened like that in the background, then come back later in some time to the Discover tab. (I’m on 24.10-RC.1) If it ended up happening to you, it’d be reproducible and then maybe worthy adding to some backlog with lowest priority.

[sfatula]

I have multi container apps. The order to stop is not terribly relevant for the most part as you said they were not starting up! I have done this with nextcloud as an example. Stop them in any order you want, maybe starting with the last one to start.

What I tended to do with multi container was start with the lowest level one first. Once that started and worked, add the next one that is dependent on the first one, etc.

Docker stop is what IX uses anyway.

[Stux]

@p0358

Since I don’t seem to be able to use “docker compose” commands even if entering the dir where the generated compose file is at.

I think it will work if you use -f and point at the rendered compose file

[p0358]

@sfatula

The order to stop is not terribly relevant for the most part as you said they were not starting up!

Yeah I may be overthinking the practical troubles with doing this. (but well, some containers would start up, but I guess the most important main one was in waiting state, so it’d be fine)

@sfatula

What I tended to do with multi container was start with the lowest level one first. Once that started and worked, add the next one that is dependent on the first one, etc.

Ha, I’d probably do it in the exact opposite way. As in to e.g. shut off the main app before shutting off its database. The logic being that app could shut down cleanly and try to commit things gracefully and disconnect before exiting. Meanwhile if database is ripped out abruptly while app is doing something (such as post-startup tasks), without the database coming back online in the lifetime of the app to reconnect and finish it up, that could potentially be much worse if unlucky.

@sfatula

Docker stop is what IX uses anyway.

I see in the docs now that multiple containers can be specified at once in the Docker command, I guess that’d be the best option then

[sfatula]

@p0358

Ha, I’d probably do it in the exact opposite way. As in to e.g. shut off the main app before shutting off its database.

I didn’t say that very well. What I MEANT was for developing the compose file. Start with the lowest level, make sure it works, then start the next level, etc, until you get to the top. I wasn’t speaking of order of stopping.

[p0358]

@sfatula

I didn’t say that very well. What I MEANT was for developing the compose file. Start with the lowest level, make sure it works, then start the next level, etc, until you get to the top. I wasn’t speaking of order of stopping.

Ah, that makes sense then.

@Stux

I think it will work if you use -f and point at the rendered compose file

It doesn’t seem to work. But thanks to that suggestion I discovered another easier method.

1. First check list of projects with docker compose ls. It will print out a table of NAME, STATUS, CONFIG FILES. The names are in format of ix-<HowYouNamedYourAppInUI>
2. Now run a command like docker compose -p ix-minio ps

Very neat, I think that solves the stopping concern and will make life easier when poking around things. Especially that specifying project name is also way more convenient than the long path of compose file, can be done out of memory. Good stuff.

Though docker inspect on running container shows these Labels:

"com.docker.compose.project": "ix-minio",
"com.docker.compose.project.config_files": "/mnt/.ix-apps/app_configs/minio/versions/1.1.9/templates/rendered/docker-compose.yaml",
"com.docker.compose.project.working_dir": "/mnt/.ix-apps/app_configs/minio/versions/1.1.9/templates/rendered",
"com.docker.compose.service": "minio",
"com.docker.compose.version": "2.29.1",

Project working dir seems to be the same dir where compose file used lays, so I’m not really sure why compose command doesn’t pick it up by file or by cd’ing there, but whatever ¯\(ツ)/¯

[DjP-iX]

@p0358

Just keep them opened like that in the background, then come back later in some time to the Discover tab. (I’m on 24.10-RC.1) If it ended up happening to you, it’d be reproducible and then maybe worthy adding to some backlog with lowest priority.

Tried this for a while, but I haven’t been able to reproduce.