Comments

• 

  about 2 months ago by mbologna | Reply

  I started an attempt some years ago:

  https://gitlab.suse.de/mbologna/sumadocker/-/tree/saltcontainer

  You can use this as a starting point: it was working as a fat container.

• 

  about 2 months ago by j_renner | Reply

  In case we wanted to build the containers in OBS, which would be my suggestion, there is some examples here of development containers we built so far, for example one that includes the database:

  https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Master:Docker

• 

  about 2 months ago by pagarcia | Reply

  What does this mean? "we will need a solution about commandline tools. Would it be possible to create a UI around them like Rancher does?"

  Do you mean in order to avoid connecting to the container to run those CLI tools in there?

  One alternative would be to build such a UI but you still have the problem this still gives you access to the "internals" of Uyuni. Ideally, we want to use the CLI tools remotely (connecting to Uyuni, Salt, database or whatever, always via single ingress endpoint), or even to replace them with proper WebUI, API, etc calls.

  • 

    about 2 months ago by moio | Reply

    Yes, the point is that there is no way to "connect to a container", unless the container runs sshd which is not the norm. One can spin up a container with just one commandline tool inside (example) but that might be cumbersome or not possible depending on the tool.

    In principle, one wants any commandline tool's functionality to be equivalently exposed via a Web UI, which is of course a good long-term goal.

    In the meantime, a stopgap solution could be to offer some commandline tools inside a text area in the Web UI. That won't be a proper shell (say, bash), but something tailored to the app such as our spacecmd. Rancher does something similar with kubectl.

    Note that I am not even convinced this is the best solution for this case here, it's just something that could be viable to speed things up.

    • 

      about 1 month ago by pagarcia | Reply

      I see your point. Makes sense. Maybe Ricardo's uyuni-cli can help here, otherwise there's a ton of tools to enable via WebUI.

      Another alternative would be to make all the CLI tools work remotely. Some of them already do.

      Another important case: logs. How to view them? Add them to the WebUI? Some tool to show logs remotely? Another thing to add to uyuni-cli?

      • 

        about 1 month ago by atgracey | Reply

        Another way to offer CLI tools is to build a container that gets run as a sidecar and can be turned on or off depending on context. Then if you wanted to give easy access, you could also package code-server in that tools container to give a nice IDE/terminal access in the browser.

        Eventually, K8s will offer ephemeral containers (alpha currently) and this would be even easier and more secure.

        (sorry if this gets duplicated, I apparently wasn't logged in while commenting the first attempt)

        • 

          about 1 month ago by moio | Reply

          That's also an interesting possibility, definitely something to consider, thanks!

      • 

        about 1 month ago by moio | Reply

        In a K8S environment, you expect the framework itself to take care of logs. It's similar to systemd - you just dump them all to stdout and then the framework handles it for you.

        Of course we might end up with fatter-than-ideal containers which contain multiple servers, and then we will need to expose logs in another way. The starting point will be a mounted directory inside of the container, then we can assess how big of a problem we actually have.

        In any case: it's a problem bleeping both under my radar and MC's!

        • 

          28 days ago by atgracey | Reply

          Loki can let you stream logs based on a set selector labels. https://grafana.com/oss/loki/

• 

  24 days ago by joachimwerner | Reply

  I played with Rancher in my own hack week project, and I came up with that exact same idea, just to realize that you guys have already been working on it.

  After this hack week, how far do you think you are away from a working helm-installable Uyuni server demo? Another hack week? Or is this a major undertaking?