Racked today, entire hosting solution based on Vates stack
-
@bvitnik stack-wise we had the equivalent on vmware (esxi hosts, pfsenses, way of managing vlans to isolate tenants) but was all manually managed.
XOA apis/websockets possibilities and our willing to do less "by hand" put us to dev this GUI, all from scratch.
we are a small team, the more it runs by itself, the more time we have to "get it done" on other topics (sell it, market it, ...) -
@nikade to be noted, on XO6 this bug does not exist anymore !
-
new VM wizard
1- Name it
2- Prep it
You choose the available pool/host/SR/network, and then template. All choices are driven top to bottom.
all filtering happening here is based on TAGs in XOA, hope XO6 will not break it
but it was also the easiest way to differentiate "templates" that are HUB templates, and "templates" that are VM config models and need an ISO
bios mode is also automagically selected by tags...
3- Customize it
Dynamic cloudconfig file creation, you fill the form, it changes the config
config is manually editable if you want to4- Deploy it
Final check before Pulumi does its magic.to be done :
- ssh-key wallet/generate button
- hash of user password to avoid plain text in cloudconfig file
- differentiate windows/linux templates to generate cloud-init/cloudbase-init files
- DB of tenant/reseller/client logic, full admin view for now
beta opens in a couple weeks max I think !
-
@Pilow just curious. Why use Pulumi for VM provisioning instead of XO API directly? You are interfacing with XO API for other stuff anyway, right?
-
@bvitnik Pulumi is more IaC ready for the type of deployement we want in a MSP context, where resellers should manage their own VMs and clients VMs. we can pulumi up VMs, and modify them after if needed. we can replay a VM deployment in different tenants contexts.
Predictability, idempotence, and the fact that Pulumi can go beyond XO provider to manage other aspects of the stack
-
@Pilow said in Racked today, entire hosting solution based on Vates stack:
... and the fact that Pulumi can go beyond XO provider to manage other aspects of the stack
Can you elaborate more?
-
@bvitnik for example use Pulumi to create DNS records in domains hosted by OVH to point to the dedicated IP of a tenant to publish a spinned up pulumi-docker app in a tenant VM.
or use the 1password Pulumi provider to store SSH Keys of deployed VMs of a client
our stack is based on PFsense api, but if next datacenter we host in we get a fortinet firewall instead, use the Pulumi provider to manage the network parts in the same Cloudbox app.
create on the fly buckets in our Minios to provide dedicated remote for a reseller backup
possibilities are quite infinite ?
-
@Pilow Ah, yes. Makes much more sense now. My mind was too focused on Vates stack that I didn't think about anything outside of it like DNS, 1password, firewall etc. integration.
You seem to have a quite good vision of what you are going to sell, both on technical level and business level. I work for cloud/managed services provider myself and we grew large but never got to this level of integration. I'm envious now
-
@bvitnik Vates stack is the central part, where the compute happens. but as we want to get the most of automation, we need to have the correct tools to orchestrate.
And I also do not want it to be "one or the other", our app should let full administration happen in XOA, in the firewalls, etc... if needed
the app will be a wrapper around different components, but should rule them all
-
Looks very promising!
Just a question, what does the customer care about what pool, host or SR the VM is deployed to? I mean that's normally nothing you get to choose at the other cloud providers i've tried.
Or is that something only available to "resellers" who might have to balance their customers?
