Another way to state my point - don't let CloudStack orchestrators do
micro-management. It is impossible to handle every case cleanly if we do
micro-management at one level. Let these orchestrators behave like people
managers,
Hey, this is the user's configuration (network config, CPU, memory,
disk etc),
This is what I have with my available facilities (physical
infrastructure),
We need to realize an execution plan (orchestration flow)
Chiradeep, I need you to work on the network (resource realization)
Kelven, I need you to work on storage (resource realization)
Do whatever you need to, you have access to the lab (service callbacks)
but please fulfill the plan (try to keep high-level orchestration flow
intact)
Kelven
> -----Original Message-----
> From: Kelven Yang [mailto:kelven.y...@citrix.com]
> Sent: Thursday, May 31, 2012 11:07 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: making VM startup more fine-grained
>
> > Another way is to modify the specific hypervisor resource to do
> something
> > just after creating the vifs but prior to starting the vm.
>
> I would go with this way. I'm proposing bi-directional communication
> between resource agent and the CloudStack kernel. Let CloudStack kernel
> only manage meta database for network configuration, virtual-to-physical
> mapping configuration etc, information that is generic, stable and
> independent of underlying resource realization technologies, Let resource
> provisioning orchestrators manage and orchestrate the process at flow-
> level, but leave the resource realization details to down-level
> components. If a down-level component needs to access the configuration
> data related with the operation, it calls back into the service API
> provided by CloudStack kernel.
>
> In this SDN example, the overall orchestration flow should not be
> affected by its implementation details, changes can be scoped at resource
> level if it has the access to the information it needs from common
> service API provided by CloudStack kernel.
>
> Kelven
>
>
>
>
>
> > -----Original Message-----
> > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> > Sent: Thursday, May 31, 2012 10:17 PM
> > To: CloudStack DeveloperList
> > Subject: making VM startup more fine-grained
> >
> > I was helping someone with their integration of an SDN controller with
> > CloudStack. The requirement was that the SDN controller needed the uuid
> > of
> > the virtual interface (vif) of the virtual machine so that it could
> plug
> > it into the right softswitch, manage the vif etc. This vif uuid is
> > generated by the XenServer.
> >
> > My recommendation was to write a plugin (implement NetworkElement) that
> > would get the vif uuid after the vm started by making a XAPI call (via
> > the
> > agent manager) and then call the SDN controller API with this value.
> > The response:
> > "Unfortunately, the mechanism you describe wouldn't be sufficient as
> we
> > would require the the VIF uuid before the VM boots, otherwise there
> might
> > be a race condition where sometimes VMs will boot up and lack network
> > connectivity and therefore might not even receive their DHCP addresses
> > and
> > such.
> > "
> > Currently, when CloudStack starts a VM, all information regarding the
> VM
> > (including nics and storage) is passed down in a single StartCommand to
> > the hypervisor resource. The hypervisor resource (e.g.,
> > CitrixResourceBase
> > or LibVirtComputingResource) takes appropriate actions to create vifs
> and
> > plug them into the vm and start the vm.
> >
> > One way to solve the integration problem would be to split the
> > StartCommand into multiple commands: for e.g., CreateVif, CreateVolume,
> > CreateVm, StartVm. This changes the agent API and affects all
> hypervisor
> > resources.
> > Another way is to modify the specific hypervisor resource to do
> something
> > just after creating the vifs but prior to starting the vm.
> > A third way is to split the agent api into 2 commands: CreateVm and
> > StartVm.
> >
> > Thoughts?
> > --
> > Chiradeep
