~rogpeppe/juju-core/azure : changes

~rogpeppe/juju-core/azure » Changes from revision 1482

From Revision 1482 to 1463

Rev	Summary	Authors	Date
1482	environs/azure: use my image environs/azure: use my image	Roger Peppe	11 years ago
1481	[r=jtv] Unify providers' user-data composition functions. [r=jtv] Unify providers' user-data composition functions. All the "physical" providers (EC2, OpenStack, MAAS, Azure) were generating user data in essentially the same way. The MAAS one looked different but actually just added an optional bit that was still completely generic. And so this branch unifies the implementations. Construction of the cloudinit.MachineConfig was lifted out of the function. That may seem arbitrary, but it's part of a greater plan: in a later step of the ongoing refactoring the construction can be lifted out of the providers' internalStartInstance methods as well, doing away with the EC2 and OpenStack providers' startInstanceParams structs. This actually shortens some of the data flows and reduces cognitive load, which can only be good for maintenance. After that step we can have a fresh look at sanitizing NewMachineConfig (which arguably should take more parameters, or not exist at all, but is in an intermediate state that facilitates the changes happening now). We may also look into re-introducing some sort of dedicated Parameter Object for internalStartInstance, but by then the cluster of methods Bootstrap / StartInstance / internalStartInstance will look a bit different and we can find the most maintainable solution for that new situation.	jtv at canonical	11 years ago
1480	[r=jameinel],[bug=1199915] cmd/jujud: Ensure valid agent.con... [r=jameinel],[bug=1199915] cmd/jujud: Ensure valid agent.conf after upgrade This fixes the agent.conf files for the machine and unit agents after upgrading from 1.10 to 1.11. I ran into a few differences, the basics are: 1) Machine Agent: machine 0 always starts the state worker, when upgrading it has an APIInfo section, but it 1a) Didn't have Machine.SetPassword in the DB set so we didn't have a way to connect via the api 1b) Didn't have a password set in apiinfo, and 1.10 had already changed the password after connecting to the MongoDB 1c) Had changed their password already So to solve this one, we grab the Password from StateInfo.Password, call Agent.SetPassword(), and set the value in APIInfo.Password. 2) Machine Agent: machine != 0. Were only connecting to the state after connecting to the API. Because of (1a,b) they couldn't connect to notice that they had work to do. So on top of what we did for (1), I added a step of: 2a) If we are unable to connect to the API, call ensureStateWorker(). This gives us an opportunity to set our API password and save it in agent.conf. 3) Unit agents: 3a) Didn't even have an APIInfo section. 3b) Did have a Mongo password, and had reset their Mongo Password So we copy the state info into the api info section, and change the port. I only use the default port (17070). I think it would be possible to query something in state for what the official API is (state.State.Environ().APIInfo() comes to mind, but I'm not sure what the correct value is.) I felt that changing the port would solve all current 1.10 users, and if we change things in the future, we can change the code. (I also just discovered that we have Conf.APIPort which may or may not be set in all the various permutations, I don't have the energy to track down 3 different versions now.) 4) Unit agents bootstrapped with 1.11.2 tools 4a) Would have a valid APIInfo section 4b) But would not have StateInfo.Password or APIInfo.Password set. This is because changing the Password now occurs when we connect to the API, not when we first connect to the Mongo DB. I added checks for this, to make sure that 1.11.3 doesn't cause us to call Unit.SetPassword(""). I did a few upgrades from 1.10 => this code, and 1.11.2 => this code, and straight bootstrapping from this code. It all seems to be up and running. I don't think I tried bootstrapping 1.10 with this code and upgrading. I hopefully captured all of these config edge cases in the test suite, so we don't have to test all the permutations manually in the future. We also need to think very carefully when we add stuff about how we will get upgrade to notice. I'm starting to think we want to tweak how upgrade works. So instead of just replacing the tools, it has a "juju upgraded" or some other command that runs the first time you are upgraded so we can put logic into that place and have it centralized. https://codereview.appspot.com/11137044/	John Arbash Meinel	11 years ago
1479	[r=gz] Check correct info attr in cloudinit.apiHostAddrs [r=gz] Check correct info attr in cloudinit.apiHostAddrs Fixes a copy/paste error in cloudinit.MachineConfig to agent.Conf conversion helper function. No test as the only codepath that uses this goes through verifyConfig which already asserts both StateInfo and APIInfo are not nil, so not possible to write a failing test using exposed functions.	Martin Packman	11 years ago
1478	[r=dimitern] state/api: Deployer client-side facade. [r=dimitern] state/api: Deployer client-side facade. Implemented all the necessary API calls for the deployer worker. This is the last step needed before the deployer can be refactored to use only the API to talk to state. Also fixed the StringsWatcher client implementation (I initially got it wrong, but since nobody was using it yet it got undetected). Few other minor issues discovered and fixed in state, adding tests as needed. https://codereview.appspot.com/11342043/ R=fwereade, themue	Dimiter Naydenov	11 years ago
1477	[r=jtv] Convert MAAS provider to loggo. [r=jtv] Convert MAAS provider to loggo. We've been told this was desired, so we might as well do it. Why keep the obsolete approach around to set a bad example?	jtv at canonical	11 years ago
1476	[r=thumper] Enable the local provider. [r=thumper] Enable the local provider. This branch changes how the local storage is handled. It really wasn't possible to have the client keep serving the storage on dynamic ports and expect other running services to work. Also we need something always acting as the storage. After discussion with William last night, we agreed that this should be a worker in the machine agent. https://codereview.appspot.com/11333043/	Tim Penhey	11 years ago
1475	[r=jtv] Fix for gwacl update. [r=jtv] Fix for gwacl update.	Gavin Panella	11 years ago
1474	[r=thumper] Conditionally install lxc [r=thumper] Conditionally install lxc There are two primary situations where we don't want the machine agent to install lxc: 1. when the machine agent is inside an lxc container as known by state 2. when the machine has been provisioned by the local provider (because it is an lxc container) When lxc is installed inside a container, it adds a bridge network device with the same defaults as the host. This kills any routing in or out of the container. Upstart provides support for setting environment variables as part of the config, and we use this to pass the provider type through. https://codereview.appspot.com/11330043/	Tim Penhey	11 years ago
1473	[r=thumper] Have the lxc manager log dir be configurable. [r=thumper] Have the lxc manager log dir be configurable. Since the local provider wants to store the log files in a different location, the ContainerManager needs to be configured with the location. The default log location is still the same, but is now able to be configured. Also factored out the function for getting the IPv4 address for a named interface. The containers have "eth0" as their network interface, so this is used to get the DNSName. https://codereview.appspot.com/11327044/	Tim Penhey	11 years ago
1472	[r=thumper] Machine agent for local provider bootstrap [r=thumper] Machine agent for local provider bootstrap If you are using a local provider, always upload tools. This uses the standard mechanism for getting tools into the local provider storage. From there the tools are unpacked the same way as an agent would normally do it, although we do cheat and go directly to the file on disk so we don't have to pretend to download it somewhere else. https://codereview.appspot.com/11327043/	Tim Penhey	11 years ago
1471	[r=thumper] Use pre-built jujud if found. [r=thumper] Use pre-built jujud if found. Instead of rebuilding jujud everytime we want to upload some tools, try to find jujud next to the juju being executed. https://codereview.appspot.com/11326043/	Tim Penhey	11 years ago
1470	[r=wallyworld] Assign clean/empty policies obey constraints [r=wallyworld] Assign clean/empty policies obey constraints The assign clean/empty policy has been updated to check the hardware characteristics of a machine and if these are incompatible with any unit constraints, the machine is not used. If there are no hardware constraints recorded because the machine is not yet provisioned, the machine is excluded (better to err on the side of caution). https://codereview.appspot.com/11208044/	Ian Booth	11 years ago
1469	[r=thumper] Add the initial bootstrap implementation. [r=thumper] Add the initial bootstrap implementation. This isn't all that is needed to bootstrap, but it is the start. In particular, this adds the mongo upstart service. This branch also adds a very simple instance implementation for the local instances. https://codereview.appspot.com/11325043/	Tim Penhey	11 years ago
1468	[r=wallyworld] add-unit supports the force-machine argument [r=wallyworld] add-unit supports the force-machine argument Semantics are the same as for deploy. Only one unit can be added with force-machine, or else an error occurs. https://codereview.appspot.com/10962046/	Ian Booth	11 years ago
1467	[r=wallyworld] Add container support to force-machine [r=wallyworld] Add container support to force-machine The deploy --force-machine option now supports containers, either deploying to existing containers or creating new ones on nominated machines. Example syntax: juju deploy mysql --force-machine 23 juju deploy mysql --force-machine 24/lxc/3 juju deploy mysql --force-machine lxc:25 The last example creates a new lxc container on machine 25. The add-machine syntax has been tweaked to remove the leading "/" from the container arg. https://codereview.appspot.com/10777044/	Ian Booth	11 years ago
1466	[r=thumper] Change the default root-dir to be in $HOME [r=thumper] Change the default root-dir to be in $HOME Instead of having the root-dir in /usr/lib/juju, make it in ~/.juju (well, $JUJU_HOME) by default. The root dir is now the environment name under the ~/.juju dir. https://codereview.appspot.com/11319044/	Tim Penhey	11 years ago
1465	[r=thumper] Add some extra tests around the sudo checks. [r=thumper] Add some extra tests around the sudo checks. Encapsulate the sudo checks, and make a function to get the uid and gid for the user. https://codereview.appspot.com/11321043/	Tim Penhey	11 years ago
1464	[r=jtv] Skip the service-label dance in Azure. [r=jtv] Skip the service-label dance in Azure. We're still working out how we're supposed to determine an instance's DNS name in Azure. We may have been chasing a red herring early on: on the one hand the documentation hinted that a service's name also formed the hostname part of its DNS name, but on the other, we were getting what looked like a randomly generated DNS name assigned by Azure. And a little dance was orchestrated around that: get the instance URL from the Deployment object, store it in the Service's label field, use the label field as the source of the DNS name. As we understand it now, the weird randomly assigned hostnames only happen in Staging deployments, and the instance URLs don't even resolve when we deploy to Production (as we must do in Juju). And so this branch does away with the little dance, uses the service name as the instance's DNS name, and rips out all code that I could find that was only there to support the dance. The service label is now a mere courtesy; it's required but we may as well set it to be identical to the service name.	jtv at canonical	11 years ago
1463	[r=jtv] Change how an Azure instance finds its ID. [r=jtv] Change how an Azure instance finds its ID. This can now come from the service name it digs out of the WALA config, rather than from the deployment ID. This means that the deployment ID no longer matters, and that in turn opens the door to multiple instances per hosted service.	jtv at canonical	11 years ago

Older »