~frankban/juju-core/minimum-units-worker : changes

~frankban/juju-core/minimum-units-worker » Changes from revision 1328

From Revision 1328 to 1309

Rev	Summary	Authors	Date
1328	Base structure for the worker. Base structure for the worker.	Francesco Banconi	10 years ago
1327	Merged min1. Merged min1.	Francesco Banconi	10 years ago
1326	[r=jameinel] state/apiserver: Implement Machiner.Watch [r=jameinel] state/apiserver: Implement Machiner.Watch Server-side implementation of the final API call needed by the machiner. R=fwereade, rogpeppe, wallyworld	Martin Packman	10 years ago
1325	[r=rogpeppe] state/apiserver: logging in changes the API [r=rogpeppe] state/apiserver: logging in changes the API This is a step towards serving just the API that each client is supposed to see. For the time being, we still have one big root object, but this will be split up in subsequent CLs. https://codereview.appspot.com/10447047/	Roger Peppe	10 years ago
1324	[r=jtv] Implement Environ.SetConfig for Azure provider. [r=jtv] Implement Environ.SetConfig for Azure provider.	Jeroen Vermeulen	10 years ago
1323	[r=rvb] Implement storage methods in the Azure provider. [r=rvb] Implement storage methods in the Azure provider.	Raphael Badin	10 years ago
1322	[r=jameinel] Remove Metadata() method from Instance interfac... [r=jameinel] Remove Metadata() method from Instance interface The machine metadata is not aways available, and is only used when startInstance is called. So have startInstance return the metadata separately along with the instance. https://codereview.appspot.com/10384049/	Ian Booth	10 years ago
1321	[r=themue] ec2: moved the http storage reader and tests [r=themue] ec2: moved the http storage reader and tests Moved the HTTP based StorageReader and the test server for it to environs/ec2 and adopted those changes at the synctools. https://codereview.appspot.com/10296046/	Frank Mueller	10 years ago
1320	[r=rogpeppe] state/apiserver/machine: add AgentAPI.SetPasswo... [r=rogpeppe] state/apiserver/machine: add AgentAPI.SetPasswords We also add the client side, and implement it in such a way that it can easily be incorporated into the unit agent API. https://codereview.appspot.com/10449044/	Roger Peppe	10 years ago
1319	[r=fwereade] state: aggressive removal of pending units [r=fwereade] state: aggressive removal of pending units In response to lp:1190715, we make the following changes: * service destruction now adds a cleanup doc that churns through all a service's units destroying or removing them where possible. * unit destruction short-circuiting is now attempted when the unit agent has not yet set a status. ...and make the following opportunistic changes for sanity's and clarity's sakes: * clarify and make consistent the similar transaction-building loops in service.go and unit.go (in particular, Unit.Remove was noticeably simplified). * resolve races around unit destruction in which charm changes and machine assignment changes are not properly taken into account. ...supported by testing changes as follows: * added SetRetryHooks for verifying a commonly-interesting-to-test scenario (set up txn; break txn; verify effect of retried txn) * SetBeforeHook became SetBeforeHooks, because that happened while I was figuring out SetRetryHooks, and I decided it was a nice change. * preventUnitDestroyRemove is much simpler and no longer needs the state argument; this is annoyingly noisy. * assertUnitLife and assertUnitRemoved were taken off UnitSuite and used elsewhere. The macroscopic effect of this is currently limited. Units that are manually removed will be removed more quickly more often, which is nice; but the big problem in lp:1190715 is related to service destruction, and that's not directly helped by this branch. When we merge a cleanup worker integration branch, though, this bug will be fixed pretty nicely for all environments running this code (on both client and server).	William Reade	10 years ago
1318	[r=rogpeppe] state/api/machineagent: new package [r=rogpeppe] state/api/machineagent: new package This provides the client side of state/apiserver/machine.AgentAPI. https://codereview.appspot.com/10437043/	Roger Peppe	10 years ago
1317	[r=rogpeppe] state/api/machiner: rename Machiner to State [r=rogpeppe] state/api/machiner: rename Machiner to State As discussed online. Also make the Machiner entry point consistent with Client by not returning an error. https://codereview.appspot.com/10364046/	Roger Peppe	10 years ago
1316	[r=rogpeppe] state/machine: new agent API [r=rogpeppe] state/machine: new agent API As discussed, for testing reasons it makes sense to place APIs for a given agent alongside one another, so this CL puts the machiner API and the machine agent API alongside one another. Client-side machine agent API in a subsequent CL. Re-proposing to avoid the prereq, which I can't submit right now. Original CL here: https://codereview.appspot.com/10398043/ https://codereview.appspot.com/10384046/	Roger Peppe	10 years ago
1315	[r=jtv] Create temporary cert file for each ManagementAPI. [r=jtv] Create temporary cert file for each ManagementAPI. For now, each high-level function in the Azure provider will create its own storage contexts and management-API objects as needed. In the case of the management API, that comes with a temporary file containing an Azure certificate. (There is another way to pass the certificate to go-curl, but we want to avoid the complications and especially the unknowns at this point). Once done with your request(s) to the management, you release it. This cleans up the certificate file, but in the future it may also serve as a hook for connection pooling. We'll treat optimization as a separate problem — it seems easy but this sort of thing often brings out creative tendencies that aren't worth the time just at the moment. As long as we don't need any actual cleanup code for the storage-API side, we chose not to create a cleanup method there. This is all internal detail after all; it doesn't affect any exported APIs.	Jeroen Vermeulen	10 years ago
1314	[r=jtv] Helper: test a function for correct locking. [r=jtv] Helper: test a function for correct locking. This is the outcome of discussion at https://code.launchpad.net/~jtv/juju-core/create-gwacl-sessions/+merge/170032 but produces a helper that is much, much simpler. It could become generic, although one thing is still missing: it currently only works for locks that are of type sync.Mutex. It probably ought to work for any type of lock. Failure of a function to acquire the right lock(s) is a constant risk in concurrent programs, so one of the things most worth testing, but it's also relatively hard to test for and so nobody ever does it. Of course if you can forget the locking you can also forget the test, but this helper makes it very easy to guard against regressions.	Jeroen Vermeulen	10 years ago
1313	[r=jameinel] Create gwacl session objects for management & A... [r=jameinel] Create gwacl session objects for management & API. I commented out one of the new functions at the last moment (as well as its test), even though the test passes. This was done because we're still working out a detail in gwacl that may result in an incompatible change. For some of the code in here, including Config(), the only interesting aspect to test really is the locking. It's the one thing that can go wrong. None of the other providers seem to test for this, and it's a bit of a losing game in that whenever you forget to lock, you're likely to forget to test for locking as well. But I wrote up a simple, reusable pattern so that at least we can guard against regressions.	Jeroen Vermeulen	10 years ago
1312	[r=themue] resumer: periodically resume transaction [r=themue] resumer: periodically resume transaction The resumer is a periodically worker which is resuming pending transactions in state each minute. https://codereview.appspot.com/10266043/	Frank Mueller	10 years ago
1311	[r=thumper] Some useful checkers. [r=thumper] Some useful checkers. Also some testing functions used later, with their own test. https://codereview.appspot.com/10395044/	Tim Penhey	10 years ago
1310	[r=jtv] Store certificate in temporary file for libcurl. [r=jtv] Store certificate in temporary file for libcurl. In order to talk to Azure, we need to pass an x509 certificate into libcurl. This normally works by giving it the name of the certificate file, and that's what gwacl supports, but code that runs on the bootstrap node won't have access to the user's certificate file. We'll have to work with the certificate's contents instead. There is apparently a way to pass the certificate contents to libcurl, but it's too complicated and has too many unknowns, so we chose to do it the ugly way first: write the certificate contents to a temporary file (with restricted access permissions, naturally) and give libcurl the file.	Jeroen Vermeulen	10 years ago
1309	[r=fwereade],[bug=1175031] uniter: don't repeat change event... [r=fwereade],[bug=1175031] uniter: don't repeat change events By putting the unit.ClearResolved onto the filter goroutine, and immediately forcing unit-change handling, we can ensure that the uniter goroutine cannot request a fresh resolved event before the filter has refreshed the unit and determined that there is no event to deliver. Handling this race should fix lp:1175031. https://codereview.appspot.com/10298043/	William Reade	10 years ago

Older »