Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(224)

Issue 10489043: Hook up the lxc-broker to the provisioner.

Can't Edit
Can't Publish+Mail
Start Review
Created:
12 years, 8 months ago by thumper
Modified:
12 years, 8 months ago
Reviewers:
mp+171034, fwereade, wallyworld
Visibility:
Public.

Description

Hook up the lxc-broker to the provisioner. How William and I discussed this was to have a new provisioner task at the machine agent level for the containers. I added a string representation for the lxc instance as I was outputting some values in logging information, and it seemed reasonable to leave this in. The mock lxc implementation gets smarter as I needed this to test an error condition that I was seeing. Inside the provisioner task, when we delete a machine, we remove it from the task's map of machines. When we then look for the unknown instances, this is done by grabbing all the instances and removing all those we know about. Since there may be a machine that we are stopping, this has been removed from the provisioner task's map, so the instance is unknown. When we try to find the instance for the stopped machines, we are looking in the task's instance map, and we find it. Since we were adding both the stopping list and the unknown list to the "stop these instances" method, we were trying to stop the same instance more than once, which was causing errors. The simplest thing was to pass the stopping list of instances through to the unknown finding method so they can be ignored. The dummy provider was very good at ignoring this completely, so the mock lxc implementation has a little more smarts, and now does return error conditions if create/start/stop/destory are called on containers with unexpected states. The mock lxc implementation now also has some event observers. New events are created for started and stopped machines. These are used in the tests to monitor the starting and stopping of the containers. I noticed that the JujuConnSuite wasn't closing the APIConn that it opened. I refactored the suites the provisioner tests used in order to get some handy function reuse. Especially when there was other state needed. Like the lxc containers still need a real machine to have been created, this needs state, and a real (or dummy) provider. The provisioner grew a few factory methods that are used to create the watchers and brokers for the particular supported types. https://code.launchpad.net/~thumper/juju-core/lxc-provisioner/+merge/171034 Requires: https://code.launchpad.net/~thumper/juju-core/provisioner-auth-provider/+merge/171006 (do not edit description out of merge proposal)

Patch Set 1 #

Patch Set 2 : Hook up the lxc-broker to the provisioner. #

Total comments: 4

Patch Set 3 : Hook up the lxc-broker to the provisioner. #

Total comments: 15

Patch Set 4 : Hook up the lxc-broker to the provisioner. #

Unified diffs Side-by-side diffs Delta from patch set Stats (+413 lines, -74 lines) Patch
A [revision details] View 1 2 3 1 chunk +2 lines, -0 lines 0 comments Download
M cmd/jujud/machine.go View 1 2 3 1 chunk +19 lines, -4 lines 0 comments Download
M container/lxc/instance.go View 1 1 chunk +5 lines, -0 lines 0 comments Download
M container/lxc/mock/mock-lxc.go View 1 6 chunks +82 lines, -3 lines 0 comments Download
M juju/testing/conn.go View 1 2 1 chunk +1 line, -0 lines 0 comments Download
M state/state.go View 1 2 1 chunk +1 line, -0 lines 0 comments Download
M worker/provisioner/export_test.go View 1 2 chunks +7 lines, -0 lines 0 comments Download
M worker/provisioner/lxc-broker.go View 1 2 chunks +5 lines, -4 lines 0 comments Download
M worker/provisioner/lxc-broker_test.go View 1 4 chunks +156 lines, -13 lines 0 comments Download
M worker/provisioner/provisioner.go View 1 2 3 5 chunks +85 lines, -8 lines 0 comments Download
M worker/provisioner/provisioner_task.go View 1 2 3 9 chunks +15 lines, -15 lines 0 comments Download
M worker/provisioner/provisioner_test.go View 1 22 chunks +35 lines, -27 lines 0 comments Download

Messages

Total messages: 5
thumper
Please take a look.
12 years, 8 months ago (2013-06-26 09:09:01 UTC) #1
thumper
Please take a look.
12 years, 8 months ago (2013-06-26 23:14:36 UTC) #2
fwereade
LGTM, lots of comments but nothing blocking anything. https://codereview.appspot.com/10489043/diff/3001/cmd/jujud/machine.go File cmd/jujud/machine.go (right): https://codereview.appspot.com/10489043/diff/3001/cmd/jujud/machine.go#newcode129 cmd/jujud/machine.go:129: provisioner.NewProvisioner(provisioner.ENVIRON, ...
12 years, 8 months ago (2013-06-26 23:34:46 UTC) #3
wallyworld
LGTM What William said plus I query of my own. Perhaps expand the code comment ...
12 years, 8 months ago (2013-06-27 00:16:56 UTC) #4
thumper
12 years, 8 months ago (2013-06-27 02:26:37 UTC) #5
Please take a look.

https://codereview.appspot.com/10489043/diff/7001/cmd/jujud/machine.go
File cmd/jujud/machine.go (right):

https://codereview.appspot.com/10489043/diff/7001/cmd/jujud/machine.go#newcod...
cmd/jujud/machine.go:172: runner.StartWorker(workerName, func() (worker.Worker,
error) {
On 2013/06/27 00:16:56, wallyworld wrote:
> I'm confused by this. I don't understand why an lxc provisoner is used for
> non-lxc containers. I know the comment says something, but it's still not
clear
> to me. How would an lxc provisioner task provision a kvm container? What does
> not embedding lxc containers have to do with it? Should the worker name
contain
> the actual container? eg "LXC-provisioner-for-KVM"? 

Extended the comment somewhat to help with that confusion.

https://codereview.appspot.com/10489043/diff/7001/juju/testing/conn.go
File juju/testing/conn.go (right):

https://codereview.appspot.com/10489043/diff/7001/juju/testing/conn.go#newcod...
juju/testing/conn.go:225: c.Assert(s.APIConn.Close(), IsNil)
On 2013/06/26 23:34:47, fwereade wrote:
> Thanks for that.
> 
> /me wonders whether this might have to do with the races davecheney was
looking
> into... ping him maybe?

Done.

https://codereview.appspot.com/10489043/diff/7001/worker/provisioner/lxc-brok...
File worker/provisioner/lxc-broker.go (right):

https://codereview.appspot.com/10489043/diff/7001/worker/provisioner/lxc-brok...
worker/provisioner/lxc-broker.go:45: lxcLogger.Infof("started lxc container for
machineId: %s, %s", machineId, inst.Id())
On 2013/06/27 00:16:56, wallyworld wrote:
> On 2013/06/26 23:34:47, fwereade wrote:
> > I'd be fine with package vars called "log" by convention.
> 
> +1 
> "logger" is the colour of my bikeshed
> 

logger is what I've used, however that one already exists at package level,
which is why I needed another.  I was torn about what to do with it, but for
now, I'm going to leave this.

Perhaps we should move the lxc broker into an lxc package under this one.

https://codereview.appspot.com/10489043/diff/7001/worker/provisioner/provisio...
File worker/provisioner/provisioner.go (right):

https://codereview.appspot.com/10489043/diff/7001/worker/provisioner/provisio...
worker/provisioner/provisioner.go:112: machineBroker,
On 2013/06/26 23:34:47, fwereade wrote:
> instance broker? even, perhaps, instance.Broker? just a thought...

I would love to move Broker into the instance package, but right now, the
instance packages doesn't have dependencies, and the Broker would bring in
state, api and constraints.

I will change the name though to instanceBroker.

https://codereview.appspot.com/10489043/diff/7001/worker/provisioner/provisio...
worker/provisioner/provisioner.go:137: if p.machine == nil {
On 2013/06/27 00:16:56, wallyworld wrote:
> This is not thread safe. Is this being used in a single threaded context? I
> guess it doesn't matter so much since we are just reading some info from
state.

Yes, getMachine is used just during the start-up process in the loop() call.  It
doesn't need to be thread-safe.

https://codereview.appspot.com/10489043/diff/7001/worker/provisioner/provisio...
File worker/provisioner/provisioner_task.go (right):

https://codereview.appspot.com/10489043/diff/7001/worker/provisioner/provisio...
worker/provisioner/provisioner_task.go:252: // have been removed from the
task.machines map.
On 2013/06/26 23:34:47, fwereade wrote:
> In a spirit purely of philosophical enquiry: would it have been equivalent to
> have just removed the machines from the map a bit later?

I did originally do that.  You had me move it in an earlier branch. I remember
saying at the time "there is a reason for this but I don't remember what it is",
so I moved it.  The reason things kept working is that the provisioner would die
and get restarted.

I think this is cleaner now.

https://codereview.appspot.com/10489043/diff/7001/worker/provisioner/provisio...
worker/provisioner/provisioner_task.go:338: logger.Errorf("cannot start the
machine as provisioned %q: %v", machine, err)
On 2013/06/26 23:34:47, fwereade wrote:
> maybe "cannot register instance for machine %v: %v"?
> 
> fwiw, machine ids have hitherto *not* been reported with quotes. This no
longer
> really makes sense, but it'd be nice to maintain consistency (and maybe do a
> big-bang fix in our copious free time).

Done.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b