Open Stack

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
>