Our spot in the OpenStack/Open Source ecosystem isn't code - and looks like it isn't clear enough - it is that we make the full open source version of OpenStack and Ceph available in an environment that is suited to those systems - not a test system, but a real multi server system.
It lets people experience OpenStack and Ceph before every having to take on architecting it - and the Ansible we used is available to them to either carry forward on our systems or for using it as the basis of anything they want to build.
These are both for paying customers and for people learning - we have set aside resources and in our business model to allow people to spin up and use the clusters so they can learn.
OpenStack and Ceph in real production is pretty hard to pull off - failure is really common and so what we are hoping is we can at least ease some of that.
We also help OpenStack itself by providing hardware for the Zuul dev pipelines.
As for who we sell to/make money/solve - these are usually mid-size companies spending between $30k and $100k per month on Cloud and we handle part of that spend. Usually because we can tune the cloud to their workload for better performance or because we are a better deal with better support than the local mega cloud...
https://openmetal.io/programs/education-and-training/
and right now from this discussion I am adding a link to that page from the Guiding Principles page. Seriously, thanks!
Also, regarding
> and the Ansible we used is available to them to either carry forward on our systems or for using it as the basis of anything they want to build.
I was expecting to find that behind the login wall, but did not. Is that something that eventually shows up on the "central" dashboard somewhere?
Speaking of that dashboard, I did eventually find the username for the nodes in the tutorial, but the inclusion of `root@` in front of the hostname can make that process a tiny bit smoother
I am pretty sure I found your account on our side - sent you an email from the system in case I can help.
The Ansible playbooks are held inside a system called Semaphore for each customer's deployment. Playbooks are specific to the servers selected. Configurations for a cluster made up of 3 X single CPU box with 128GB of RAM with a single worker drive vs 3X a dual CPU box, 1TB RAM, and 4 worker drives. We copy it to the servers for now as we are still working on making Semaphore accessible from the Central interface.
For the root@ - thanks! Will pass that to the dev team - I found some with it and some without it, makes sense to have it on all since it is root keys.
Is your pitch that you use open source first, or that you are open source first?
I would actually really enjoy if https://docs.openstack.org/devstack/zed/guides/single-vm.htm... worked because moto only goes so far, whereas if I had the ability to actually do AWS-y stuff in a VM it would enable a lot more realistic tests than either localstack or moto offer
Which brings us back to your post: the website seems to be targeting so many different audiences, and at such differing levels of "hand waveiness" that it's hard to tell what problem paying you would solve. Is it just that you're taking the pain out of provisioning OpenStack and then good luck? Are you trying to take the localstack model of "open source, but operationalized" in order to add more surface area onto OpenStack (and then hopefully feeding those contributions back into OpenStack)?