[vdi][daas][ops] What are your solutions to VDI/DaaS on OpenStack?
Hello Fellow OpenStackers, I am wondering if and how OpenStackers are approaching the subject of VDI (Virtual Desktop Infrastructure), also nowadays commonly called DaaS (Desktop as a Service) offering. To be more specific, I am looking forward to a solution covering both Linux and Windows desktops, pre-OS screen access optional, well-integrated (i.e., having automation) with OpenStack Nova, preferably also with Cinder and Glance, optionally with Keystone (apart from self-auth of course!) and Heat, 3D acceleration optional (most of the desktops here don't need it), nice to have read-only sharing of screen. A search brought me to vdi-broker [1] [2] with Guacamole. [3] But the vdi-broker seems dead with no documentation whatsoever. I know Guacamole but normally it offers only static definition of connections to existing machines (VNC or RDP). Looking forward to hearing (reading :D ) your experience with VDI/DaaS on an OpenStack cloud offering. I am also open to collaboration should any of you share the same interest. We can have a relevant SIG created if that is the case. PS: Sadly, I am not able to attend the Berlin summit due to other commitments, so can't ask in person. ;-( [1] https://github.com/cloudbase/vdi-broker [2] https://www.openstack.org/videos/boston-2017/virtual-desktop-infrastructure-... [3] https://guacamole.apache.org/ Kind regards, -yoctozepto
Hi Radosław,
I am wondering if and how OpenStackers are approaching the subject of VDI (Virtual Desktop Infrastructure), also nowadays commonly called DaaS (Desktop as a Service) offering. To be more specific, I am looking forward to a solution covering both Linux and Windows desktops, pre-OS screen access optional, well-integrated (i.e., having automation) with OpenStack Nova, preferably also with Cinder and Glance, optionally with Keystone (apart from self-auth of course!) and Heat, 3D acceleration optional (most of the desktops here don't need it), nice to have read-only sharing of screen.
We just launched a service like this on the Nectar Research Cloud. Like you, I looked around but couldn't find any Open Source projects that would be suitable. In the end, we based ours on a project from the University of Melbourne that did initially support Windows, but we removed some of that support to simplify our codebase as we didn't need it. We called it Bumblebee, and the code is here: https://github.com/NeCTAR-RC/bumblebee It's a Django web app with a Redis-based task scheduler that launches Nova instances, booted from a Cinder volume, cloned from a base OS image. The Django app directly modifies Guacamole's database to create the connections once the OpenStack resources have been provisioned and provides the user with a link that takes them to their desktop. We used Keycloak with OIDC for authentication on the web app and Guacamole and it's fairly seamless transitioning between the two. We did initially look at using Heat, but we wanted to support a workflow of being able to destroy the VM and archive the OS image to Swift (and restore again later if needed) so it was easier to just manage the resources directly. There's no 3D acceleration in our solution yet, but we're planning on looking at things like virtual GPUs later on. Sadly, I'm not going to make it to Berlin either, but I was thinking it might make for a good talk at the next summit. I'm in the process of properly documenting it now, so I don't have much to share at this point, but I'm happy to go into more detail about anything. cheers, Andy
This sounds super interesting. While not a VDI user, I can see a huge appeal. Maybe this might be an interesting topic for OpenInfra Live? https://openinfra.dev/live/ On Wed, Jun 1, 2022 at 4:14 PM Andy Botting <andy@andybotting.com> wrote:
Hi Radosław,
I am wondering if and how OpenStackers are approaching the subject of VDI (Virtual Desktop Infrastructure), also nowadays commonly called DaaS (Desktop as a Service) offering. To be more specific, I am looking forward to a solution covering both Linux and Windows desktops, pre-OS screen access optional, well-integrated (i.e., having automation) with OpenStack Nova, preferably also with Cinder and Glance, optionally with Keystone (apart from self-auth of course!) and Heat, 3D acceleration optional (most of the desktops here don't need it), nice to have read-only sharing of screen.
We just launched a service like this on the Nectar Research Cloud. Like you, I looked around but couldn't find any Open Source projects that would be suitable.
In the end, we based ours on a project from the University of Melbourne that did initially support Windows, but we removed some of that support to simplify our codebase as we didn't need it.
We called it Bumblebee, and the code is here: https://github.com/NeCTAR-RC/bumblebee
It's a Django web app with a Redis-based task scheduler that launches Nova instances, booted from a Cinder volume, cloned from a base OS image.
The Django app directly modifies Guacamole's database to create the connections once the OpenStack resources have been provisioned and provides the user with a link that takes them to their desktop.
We used Keycloak with OIDC for authentication on the web app and Guacamole and it's fairly seamless transitioning between the two.
We did initially look at using Heat, but we wanted to support a workflow of being able to destroy the VM and archive the OS image to Swift (and restore again later if needed) so it was easier to just manage the resources directly.
There's no 3D acceleration in our solution yet, but we're planning on looking at things like virtual GPUs later on.
Sadly, I'm not going to make it to Berlin either, but I was thinking it might make for a good talk at the next summit.
I'm in the process of properly documenting it now, so I don't have much to share at this point, but I'm happy to go into more detail about anything.
cheers, Andy
This sounds super interesting. While not a VDI user, I can see a huge appeal.
Maybe this might be an interesting topic for OpenInfra Live? https://openinfra.dev/live/
Yeah, I could be down for that. Live demos are the best
On Thu, 2 Jun 2022 at 01:10, Andy Botting <andy@andybotting.com> wrote:
Hi Radosław,
Hi Andy,
I am wondering if and how OpenStackers are approaching the subject of VDI (Virtual Desktop Infrastructure), also nowadays commonly called DaaS (Desktop as a Service) offering. To be more specific, I am looking forward to a solution covering both Linux and Windows desktops, pre-OS screen access optional, well-integrated (i.e., having automation) with OpenStack Nova, preferably also with Cinder and Glance, optionally with Keystone (apart from self-auth of course!) and Heat, 3D acceleration optional (most of the desktops here don't need it), nice to have read-only sharing of screen.
We just launched a service like this on the Nectar Research Cloud. Like you, I looked around but couldn't find any Open Source projects that would be suitable.
In the end, we based ours on a project from the University of Melbourne that did initially support Windows, but we removed some of that support to simplify our codebase as we didn't need it.
We called it Bumblebee, and the code is here: https://github.com/NeCTAR-RC/bumblebee
It's a Django web app with a Redis-based task scheduler that launches Nova instances, booted from a Cinder volume, cloned from a base OS image.
The Django app directly modifies Guacamole's database to create the connections once the OpenStack resources have been provisioned and provides the user with a link that takes them to their desktop.
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.
We used Keycloak with OIDC for authentication on the web app and Guacamole and it's fairly seamless transitioning between the two.
We did initially look at using Heat, but we wanted to support a workflow of being able to destroy the VM and archive the OS image to Swift (and restore again later if needed) so it was easier to just manage the resources directly.
Yeah, that's not a problem at all for me, the reasoning is sensible.
There's no 3D acceleration in our solution yet, but we're planning on looking at things like virtual GPUs later on.
Sadly, I'm not going to make it to Berlin either, but I was thinking it might make for a good talk at the next summit.
Regarding this, I agree with Julia. I think OpenInfra Live would benefit from a VDI/DaaS-oriented session.
I'm in the process of properly documenting it now, so I don't have much to share at this point, but I'm happy to go into more detail about anything.
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. 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. 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. Kind regards, -yoctozepto [1] https://docs.openstack.org/kolla/latest/
cheers, Andy
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 Kind regards, -yoctozepto
Hi Radosław,
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) 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.
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.
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 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
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.
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. cheers, Andy
On Wed, 8 Jun 2022 at 01:19, Andy Botting <andy@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
We leverage guacamole within our codebase. Granted we do not have it tied explicitly into the various function of OpenStack. We use it currently as a service that resides on our controller and only have it tied into our galera cluster for db. We then leverage a separate tool for creating the users and connections to the various environments. We also published a pypi package 'guacamole-api-wrapper' for Interacting with guacamole's api. https://gitlab.com/gacybercenter/gacyberrange/projects/kinetic https://gitlab.com/gacybercenter/gacyberrange/projects/guacamole-api-wrapper https://pypi.org/project/guacamole-api-wrapper/ Jonathan Race Cyber Range Engineer | Georgia Cyber Range GEORGIA CYBER CENTER 100 Grace Hopper Lane | Augusta, Georgia | 30901 (c) 762-716-7733 www.gacyberrange.org -----Original Message----- From: Radosław Piliszek <radoslaw.piliszek@gmail.com> Sent: Monday, June 27, 2022 11:21 AM To: Andy Botting <andy@andybotting.com> Cc: openstack-discuss <openstack-discuss@lists.openstack.org> Subject: [EXTERNAL] Re: [vdi][daas][ops] What are your solutions to VDI/DaaS on OpenStack? CAUTION: EXTERNAL SENDER This email originated from an external source. Please exercise caution before opening attachments, clicking links, replying, or providing information to the sender. If you believe it to be fraudulent, contact the AU Cybersecurity Hotline at 72-CYBER (2-9237 / 706-722-9237) or 72CYBER@augusta.edu. ________________________________ On Wed, 8 Jun 2022 at 01:19, Andy Botting <andy@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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgua cozy.readthedocs.io%2F&data=05%7C01%7Cjrace%40augusta.edu%7C0bae57 2ce5504767b36b08da5850be84%7C8783ac6bd05b4292b483e65f1fdfee91%7C0%7C0% 7C637919401065166186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=86 N0GNnBVmPvZBgef3y4ZN2bxbRV4d0tKGuqmBxh6XA%3D&reserved=0)
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith ub.com%2FNeCTAR-RC%2Fbumblebee-helm&data=05%7C01%7Cjrace%40augusta .edu%7C0bae572ce5504767b36b08da5850be84%7C8783ac6bd05b4292b483e65f1fdf ee91%7C0%7C0%7C637919401065166186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C &sdata=ylD9k2jVOE9O3SPnT%2BCVmsDgUsJnJgXa0D%2Fu9v2lnqQ%3D&rese rved=0
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith ub.com%2FNeCTAR-RC%2Fbumblebee-images&data=05%7C01%7Cjrace%40augus ta.edu%7C0bae572ce5504767b36b08da5850be84%7C8783ac6bd05b4292b483e65f1f dfee91%7C0%7C0%7C637919401065166186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C% 7C&sdata=Zuyd0TDTxEKwojCN67pZe5iyH5jcQx4UHzS14eKLNiA%3D&reserv ed=0
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli nk.springer.com%2Fchapter%2F10.1007%2F978-3-030-99191-3_12&data= 05%7C01%7Cjrace%40augusta.edu%7C0bae572ce5504767b36b08da5850be84%7C8 783ac6bd05b4292b483e65f1fdfee91%7C0%7C0%7C637919401065166186%7CUnkno wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MIKr%2BsAl4D3V5cdASEJZ26h2 a6mKxugaRi1rdS7MSzc%3D&reserved=0
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... -yoctozepto
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-%20B... Cheers, Radek -yoctozepto On Mon, 27 Jun 2022 at 17:21, Radosław Piliszek <radoslaw.piliszek@gmail.com> wrote:
On Wed, 8 Jun 2022 at 01:19, Andy Botting <andy@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
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@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-%20B...
Cheers, Radek -yoctozepto
On Mon, 27 Jun 2022 at 17:21, Radosław Piliszek <radoslaw.piliszek@gmail.com> wrote:
On Wed, 8 Jun 2022 at 01:19, Andy Botting <andy@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
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@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@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-%20B...
Cheers, Radek -yoctozepto
On Mon, 27 Jun 2022 at 17:21, Radosław Piliszek <radoslaw.piliszek@gmail.com> wrote:
On Wed, 8 Jun 2022 at 01:19, Andy Botting <andy@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
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-%20B... [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-%20B...
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
Hi Radek, Exactly - I think that format makes a lot of sense. Can you start a separate thread with me and the other folks you’re in touch with so we can discuss timing and what all we would like to cover? Thanks, Allison
On Jul 7, 2022, at 2:26 AM, Radosław Piliszek <radoslaw.piliszek@gmail.com> 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@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@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-%20B...
Cheers, Radek -yoctozepto
On Mon, 27 Jun 2022 at 17:21, Radosław Piliszek <radoslaw.piliszek@gmail.com> wrote:
On Wed, 8 Jun 2022 at 01:19, Andy Botting <andy@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
participants (7)
-
Allison Price
-
Andy Botting
-
Julia Kreger
-
Manuel Bentele
-
Race, Jonathan
-
Radosław Piliszek
-
tolga＠etom.com.tr