Open Stack

Hi Allison,

I am also in touch with folks at rz.uni-freiburg.de who are also
interested in this topic. We might be able to gather a panel for
discussion. I think we need to introduce the topic properly with some
presentations and then move onto a discussion if time allows (I
believe it will as the time slot is 1h and the presentations should
not be overly detailed for an introductory session).

Cheers,
Radek
-yoctozepto

On Wed, 6 Jul 2022 at 23:12, Allison Price <allison at openinfra.dev> wrote:
>
> I wanted to follow up on this thread as well as I know highlighting some of this work and perhaps even doing a live demo on OpenInfra Live was something that was discussed.
>
> Andy and Radoslaw - would this be something you would be interested in helping to move forward? If there are others that would like to help drive, please let me know.
>
> Cheers,
> Allison
>
> > On Jul 4, 2022, at 3:33 AM, Radosław Piliszek <radoslaw.piliszek at gmail.com> wrote:
> >
> > Just a quick follow up - I was permitted to share a pre-published
> > version of the article I was citing in my email from June 4th. [1]
> > Please enjoy responsibly. :-)
> >
> > [1] https://github.com/yoctozepto/openstack-vdi/blob/main/papers/2022-03%20-%20Bentele%20et%20al%20-%20Towards%20a%20GPU-accelerated%20Open%20Source%20VDI%20for%20OpenStack%20(pre-published).pdf
> >
> > Cheers,
> > Radek
> > -yoctozepto
> >
> > On Mon, 27 Jun 2022 at 17:21, Radosław Piliszek
> > <radoslaw.piliszek at gmail.com> wrote:
> >>
> >> On Wed, 8 Jun 2022 at 01:19, Andy Botting <andy at andybotting.com> wrote:
> >>>
> >>> Hi Radosław,
> >>
> >> Hi Andy,
> >>
> >> Sorry for the late reply, been busy vacationing and then dealing with COVID-19.
> >>
> >>>> First of all, wow, that looks very interesting and in fact very much
> >>>> what I'm looking for. As I mentioned in the original message, the
> >>>> things this solution lacks are not something blocking for me.
> >>>> Regarding the approach to Guacamole, I know that it's preferable to
> >>>> have guacamole extension (that provides the dynamic inventory)
> >>>> developed rather than meddle with the internal database but I guess it
> >>>> is a good start.
> >>>
> >>> An even better approach would be something like the Guacozy project
> >>> (https://guacozy.readthedocs.io)
> >>
> >> I am not convinced. The project looks dead by now. [1]
> >> It offers a different UI which may appeal to certain users but I think
> >> sticking to vanilla Guacamole should do us right... For the time being
> >> at least. ;-)
> >>
> >>> They were able to use the Guacmole JavaScript libraries directly to
> >>> embed the HTML5 desktop within a React? app. I think this is a much
> >>> better approach, and I'd love to be able to do something similar in
> >>> the future. Would make the integration that much nicer.
> >>
> >> Well, as an example of embedding in the UI - sure. But it does not
> >> invalidate the need to modify Guacamole's database or write an
> >> extension to it so that it has the necessary creds.
> >>
> >>>>
> >>>> Any "quickstart setting up" would be awesome to have at this stage. As
> >>>> this is a Django app, I think I should be able to figure out the bits
> >>>> and bolts to get it up and running in some shape but obviously it will
> >>>> impede wider adoption.
> >>>
> >>> Yeah I agree. I'm in the process of documenting it, so I'll aim to get
> >>> a quickstart guide together.
> >>>
> >>> I have a private repo with code to set up a development environment
> >>> which uses Heat and Ansible - this might be the quickest way to get
> >>> started. I'm happy to share this with you privately if you like.
> >>
> >> I'm interested. Please share it.
> >>
> >>>> On the note of adoption, if I find it usable, I can provide support
> >>>> for it in Kolla [1] and help grow the project's adoption this way.
> >>>
> >>> Kolla could be useful. We're already using containers for this project
> >>> now, and I have a helm chart for deploying to k8s.
> >>> https://github.com/NeCTAR-RC/bumblebee-helm
> >>
> >> Nice! The catch is obviously that some orgs frown upon K8s because
> >> they lack the necessary know-how.
> >> Kolla by design avoids the use of K8s. OpenStack components are not
> >> cloud-native anyway so benefits of using K8s are diminished (yet it
> >> makes sense to use K8s if there is enough experience with it as it
> >> makes certain ops more streamlined and simpler this way).
> >>
> >>> Also, an important part is making sure the images are set up correctly
> >>> with XRDP, etc. Our images are built using Packer, and the config for
> >>> them can be found at https://github.com/NeCTAR-RC/bumblebee-images
> >>
> >> Ack, thanks for sharing.
> >>
> >>>> Also, since this is OpenStack-centric, maybe you could consider
> >>>> migrating to OpenDev at some point to collaborate with interested
> >>>> parties using a common system?
> >>>> Just food for thought at the moment.
> >>>
> >>> I think it would be more appropriate to start a new project. I think
> >>> our codebase has too many assumptions about the underlying cloud.
> >>>
> >>> We inherited the code from another project too, so it's got twice the cruft.
> >>
> >> I see. Well, that's good to know at least.
> >>
> >>>> Writing to let you know I have also found the following related paper: [1]
> >>>> and reached out to its authors in the hope to enable further
> >>>> collaboration to happen.
> >>>> The paper is not open access so I have only obtained it for myself and
> >>>> am unsure if licensing permits me to share, thus I also asked the
> >>>> authors to share their copy (that they have copyrights to).
> >>>> I have obviously let them know of the existence of this thread. ;-)
> >>>> Let's stay tuned.
> >>>>
> >>>> [1] https://link.springer.com/chapter/10.1007/978-3-030-99191-3_12
> >>>
> >>> This looks interesting. A collaboration would be good if there is
> >>> enough interest in the community.
> >>
> >> I am looking forward to the collaboration happening. This could really
> >> liven up the OpenStack VDI.
> >>
> >> [1] https://github.com/paidem/guacozy/
> >>
> >> -yoctozepto
> >
>