|
|
|
Azure provider: map instances onto Azure services.
We had to change our strategy w.r.t. how the Azure provider maps Juju instances onto Azure's objects. Our original plan was to use a Service as a container for all the Deployments created by the provider, each of these deployments corresponding to a Juju node. This is graphical representation of the model we had in mind:
Account >
- Hosted Service (container configured in the juju config)
- Deployment 1 (juju instance 1)
- VM
- Deployment 2 (juju instance 2)
- VM
- Deployment 3 (juju instance 3)
- VM
We thought we could use Service as a container of Deployments (and thus, VMs). But we can't! It turns out a Service can only be deployed to "staging" and to "production"... and those are its two Deployments. You can't add more.
Here is the Azure model as we now know it:
Account >
- Hosted Service 1 >
- Deployment, production slot >
- VM
- VM
- Deployment, staging slot >
- VM
- VM
- Hosted Service 2 >
We discussed our options with the Red Squad and mgz and reached the conclusion that having one hosted service per Juju instance is the only reasonnable solution to accomodate Juju's model with how Azure's structure. We're going with: one Juju Instance is one Azure Service, containing one Deployment, containing one VM.
Account > (container configured in the juju config)
- Hosted Service 1 (juju instance 1)
- Deployment 1
- VM
- Hosted Service 2 (juju instance 2)
- deployment 2
- VM
- Hosted Service 3 (juju instance 3)
- deployment 3
- VM
In this branch, I change the code from the old model to the new. The changes are surprinsingly straighforward:
- In Environ.Instances() and Environ.AllInstances(), use the gwacl method to list the hosted services instead of the method used to list deployments.
- Use the gwacl object representing a Service instead of the one representing a Deployment inside the instance.go:azureInstance object. Note that the hostname of the Azure instance, which is stored by Azure on the Deployment object, will be copied over (by the Azure provider, when the hosted service and the deployment will be created) in the Hosted Service's base64-encoded 'Label' field. This is mainly a convenient shortcut to avoid having to fetch the Deployment inside each Service when we want a list of the instances' hostnames.
- Get rid of the management hosted service name config item.
https://code.launchpad.net/~rvb/juju-core/use-hosted-services/+merge/173140
(do not edit description out of merge proposal)
Patch Set 1 #
Total comments: 1
Total messages: 4
|
rvb
Please take a look.
|
12 years, 6 months ago (2013年07月05日 09:04:43 UTC) #1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Please take a look.
LGTM I think you are losing the environment grouping you used to have (because one storage name was intended to be used for all instances in an env). So we'll need to consider how we get that back. Otherwise, looks good. https://codereview.appspot.com/10959043/diff/1/environs/azure/environ.go File environs/azure/environ.go (right): https://codereview.appspot.com/10959043/diff/1/environs/azure/environ.go#newc... environs/azure/environ.go:190: hostedServices, err := context.ListHostedServices() I'm not seeing where you are filtering the list of available services by something that restricts it to just the current environment. You should be able to have 2 juju environments running with the same user account, and not have them step on eachother. (And not have 'juju destroy-environment' end up destroying both environments.) I believe in the Openstack provider we set the instance name according to a pattern that includes the environment name. Something like "juju $ENV 0". Then when we query for all instances, we can filter based on that prefix. It doesn't have to be done in this patch, but you'll want to consider how you are modelling multiple environments in the same Azure account.
On 2013年07月05日 10:23:54, jameinel wrote: > LGTM > > I think you are losing the environment grouping you used to have (because one > storage name was intended to be used for all instances in an env). So we'll need > to consider how we get that back. > > Otherwise, looks good. > > https://codereview.appspot.com/10959043/diff/1/environs/azure/environ.go > File environs/azure/environ.go (right): > > https://codereview.appspot.com/10959043/diff/1/environs/azure/environ.go#newc... > environs/azure/environ.go:190: hostedServices, err := > context.ListHostedServices() > I'm not seeing where you are filtering the list of available services by > something that restricts it to just the current environment. > > You should be able to have 2 juju environments running with the same user > account, and not have them step on eachother. (And not have 'juju > destroy-environment' end up destroying both environments.) > > I believe in the Openstack provider we set the instance name according to a > pattern that includes the environment name. > > Something like "juju $ENV 0". Then when we query for all instances, we can > filter based on that prefix. > > It doesn't have to be done in this patch, but you'll want to consider how you > are modelling multiple environments in the same Azure account. Thanks for the review jam! I think you're right, we should support having 2 juju environments running with the same user account. I'm adding something similar to what the Openstack provider does.
LGTM, pending StartInstance etc implementation. I'll echo John's comment that including the environment name and machine tag in the service name seems like a good idea, compare environs/openstack/provider.go machineFullName and machinesFilter.