Code review comment for lp:~axwalk/juju-core/synchronous-bootstrap
Revision history for this message
| Andrew Wilkins (axwalk) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
On 2013/12/02 14:54:09, fwereade wrote:
> This is *great*. Thanks very much. It would be really nice to have an
initial
> line saying "Launching instance", followed by the actual instance id
that got
> started -- and maybe to finish by running juju status -- but those are
just
> details.
I've added the "Launching instance" message. Leaving the status bit for
now; that can easily be added in afterwards, and is somewhat separate
from this CL.
> So LGTM modulo trivials below, assuming jam is happy; and a few
followup
> questions:
> 1) Can we drop the secrets dance soon? (I guess we still need it for
the first
> connect to 1.16 via state :/... but maybe we don't need it for the
API)
Yes, I intend to kill it soon.
> 2) How close are we to writing the state server address directly into
the .jenv,
> so we get fast API connections from the word go? I'd be really keen to
see that
> followup soon :).
I don't know, that wasn't part of my plan. Sounds easy enough.
> 3) Which SSH commands do we still use? I think it's just debug-log
that goes
> over the API now, so ssh, scp, and debug-hooks are all still SSHy AIUI
-- can we
> consolidate those bits now? Any I didn't think of?
debug-log still uses SSH; it only uses the API for getting the address.
IIANM, TheMue is looking at changing this.
ssh, scp, debug-* all use SSH, as do environs/manual,
environs/
utils/ssh.
> 4) How hard will it be to extract the manual-provisioning code such
that it's
> possible to run a "juju register" command on an instance that you want
to
> provision and already have direct access to? I think we touched on
this a while
> back, but I'm not sure we came to any conclusion.
The SSH-bits could easily be pretty easily swapped to use os/exec
Command, so it's all on localhost. The challenging bit will be how to
package configuration in a nice way.
> Oh! And, can we run in-environment storage everywhere soon? This
doesn't handle
> the bootstrap-state case ofc, but it would be great to keep charms and
tools
> inside the environment.
I can still see one major problem, which is that you couldn't then
sync-tools before bootstrapping. Other than that, I think it should be
doable.
https:/
> File cloudinit/
https:/
> cloudinit/
environs.
> &testProvider{})
> Can we stick an explicit "test" into the name somewhere please?
https:/
> File environs/
https:/
> environs/
doesn't exist,
> juju don't carea
> s/carea/care/
https:/
> File provider/
https:/
> provider/
signal
> handling.
> I'd like this to be an imminent followup, please :).
https:/
> provider/
env.StartInstan
> selectedTools, machineConfig)
> Wouldn't this still work with :=, even given inst? Maybe I'm still
sluggish
> after lunch...
https:/
> File provider/
https:/
> provider/
func(*common.
> instance.Instance, *cloudinit.
> Let's log something in here so that there's some way of diagnosing
what happened
> if Disable gets called in a surprising situation.
https:/
> File provider/
https:/
> provider/
> "launchpad.
> Oh, a thought. Might DisableFinishBo
environs/testing?
> https:/
> File utils/ssh/ssh.go (left):
https:/
> utils/ssh/
cmd/juju, and
> others.
> Can the SSHy bits in cmd/juju use this now?
https:/