<div>Hello everyone,</div><div> </div><div>As Etom Cloud, we already developed our own VDI solution on top of existing services like Guacamole. Unfortunately, it is not available on-demand on our public cloud yet due to lack of demand.</div><div> </div><div>We used guacamole within our solution but it's not enough to offer a VDI as a service solution.</div><div> </div><div>Therefore we developed end-user onboarding tools and multi-platform desktop applications just like AWS Workspace does.</div><div> </div><div>We have our own AWS Console-like solution instead of OpenStack horizon, so we can develop these kinds of different service models.</div><div> </div><div>For instance, each VDI end-user can log in to our customer portal and reach their own pre-assigned VDI, or they can download their desktop application to reach their own VDI with minimum efforts. All further access management or billing issues are handled by our solution. Even end-users can contact directly with our cloud support using the same solution.</div><div> </div><div>We can offer this a turnkey solution including OpenStack itself or we can deploy on it your OpenStack if your environment (if it meets minimum requirements)</div><div> </div><div><div>It is not just limited to the VDI service, we also have different kinds of services with the same point of view. Most of the solutions are backed with open source, therefore you will not have any vendor lock in for the future.</div></div><div> </div><div>If someone is interested in this, we can schedule a call.</div><div> </div><div>Regards,</div><div> </div><div> </div><div>08.06.2022, 02:23, "Andy Botting" <andy@andybotting.com>:</div><blockquote><p>Hi Radosław,<br /> </p><blockquote> First of all, wow, that looks very interesting and in fact very much<br /> what I'm looking for. As I mentioned in the original message, the<br /> things this solution lacks are not something blocking for me.<br /> Regarding the approach to Guacamole, I know that it's preferable to<br /> have guacamole extension (that provides the dynamic inventory)<br /> developed rather than meddle with the internal database but I guess it<br /> is a good start.</blockquote><p><br />An even better approach would be something like the Guacozy project<br />(<a href="https://guacozy.readthedocs.io/" rel="noopener noreferrer">https://guacozy.readthedocs.io</a>)<br /><br />They were able to use the Guacmole JavaScript libraries directly to<br />embed the HTML5 desktop within a React? app. I think this is a much<br />better approach, and I'd love to be able to do something similar in<br />the future. Would make the integration that much nicer.<br /> </p><blockquote><br /> Any "quickstart setting up" would be awesome to have at this stage. As<br /> this is a Django app, I think I should be able to figure out the bits<br /> and bolts to get it up and running in some shape but obviously it will<br /> impede wider adoption.</blockquote><p><br />Yeah I agree. I'm in the process of documenting it, so I'll aim to get<br />a quickstart guide together.<br /><br />I have a private repo with code to set up a development environment<br />which uses Heat and Ansible - this might be the quickest way to get<br />started. I'm happy to share this with you privately if you like.<br /> </p><blockquote> On the note of adoption, if I find it usable, I can provide support<br /> for it in Kolla [1] and help grow the project's adoption this way.</blockquote><p><br />Kolla could be useful. We're already using containers for this project<br />now, and I have a helm chart for deploying to k8s.<br /><a href="https://github.com/NeCTAR-RC/bumblebee-helm" rel="noopener noreferrer">https://github.com/NeCTAR-RC/bumblebee-helm</a><br /><br />Also, an important part is making sure the images are set up correctly<br />with XRDP, etc. Our images are built using Packer, and the config for<br />them can be found at <a href="https://github.com/NeCTAR-RC/bumblebee-images" rel="noopener noreferrer">https://github.com/NeCTAR-RC/bumblebee-images</a><br /> </p><blockquote> Also, since this is OpenStack-centric, maybe you could consider<br /> migrating to OpenDev at some point to collaborate with interested<br /> parties using a common system?<br /> Just food for thought at the moment.</blockquote><p><br />I think it would be more appropriate to start a new project. I think<br />our codebase has too many assumptions about the underlying cloud.<br /><br />We inherited the code from another project too, so it's got twice the cruft.<br /> </p><blockquote> Writing to let you know I have also found the following related paper: [1]<br /> and reached out to its authors in the hope to enable further<br /> collaboration to happen.<br /> The paper is not open access so I have only obtained it for myself and<br /> am unsure if licensing permits me to share, thus I also asked the<br /> authors to share their copy (that they have copyrights to).<br /> I have obviously let them know of the existence of this thread. ;-)<br /> Let's stay tuned.<br /><br /> [1] <a href="https://link.springer.com/chapter/10.1007/978-3-030-99191-3_12" rel="noopener noreferrer">https://link.springer.com/chapter/10.1007/978-3-030-99191-3_12</a></blockquote><p><br />This looks interesting. A collaboration would be good if there is<br />enough interest in the community.<br /><br />cheers,<br />Andy</p></blockquote><div> </div><div> </div><div>-- </div><div>Tolga KAPROL</div><div>CTO, ETOM Cloud</div><div> </div>