Open Stack

Hi developers,

After an invitation from Radosław, I join the VDI discussion as well. 
I'm one of the authors of the OpenStack VDI paper [1] mentioned by 
Radosław. The paper is now freely accessible to everyone in the 
pre-published version [2]. Thank you Radosław for sharing.

The main repository mentioned in the OpenStack VDI paper is currently 
hosted on GitHub [3] and contains configurations for general testing and 
development purposes (for me and my colleagues). The repository also 
provides a little DevStack setup for some simple VDI tests based on the 
functionality that OpenStack already provides. If we aim for a more 
active development in the future, we can also move the repository to 
another more official location.

Our needs for a VDI solution are already outlined in our paper [1]. We 
are currently hosting part of the bwCloud [4] infrastructure and a HPC 
cluster [5]. Researchers and students can carry out computations there. 
However, we are receiving more and more requests from these people to 
offer virtual (powerful) graphical desktops for graphic(-intense) 
applications, so that computation results can be visualized or other use 
cases can be covered (e.g. office work). That's why we've had the idea 
of a free VDI solution for a long time, where we now (hopefully) 
initiated a further development with our published paper.I'm looking 
forward to further exciting ideas and a great cooperation with all 
interested people from the OpenStack community.

[1] https://doi.org/10.1007/978-3-030-99191-3_12
[2] 
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
[3] https://github.com/bwLehrpool/osvdi
[4] https://www.bw-cloud.org/en/
[5] https://www.nemo.uni-freiburg.de

Regards,
Manuel

On 7/7/22 11:26, radoslaw.piliszek at gmail.com (Radosław Piliszek) wrote:
> 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
>