Open Stack

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 at gmail.com> 
Sent: Monday, June 27, 2022 11:21 AM
To: Andy Botting <andy at andybotting.com>
Cc: openstack-discuss <openstack-discuss at 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 at augusta.edu.

________________________________

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://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%2Fpaidem%2Fguacozy%2F&data=05%7C01%7Cjrace%40augusta.edu%7C0bae572ce5504767b36b08da5850be84%7C8783ac6bd05b4292b483e65f1fdfee91%7C0%7C0%7C637919401065166186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wr0XGRY86LmYCgYM5TVo3oLso9mB7BOJiYTkk7PaYeY%3D&reserved=0

-yoctozepto