<div dir="ltr">On Tue, Sep 10, 2013 at 1:01 AM, Nate Finch <span dir="ltr"><<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><p dir="ltr">I'm pretty interested in this, actually, since I want to be able to use juju to deploy charms to a VPS I have... but even with this change, it's not workable, because we can't manually choose a machine to bootstrap to. Needing an AWS machine (or similar) as machine 0 is pretty much a deal breaker.</p>
</div></blockquote><div>One option you have right now is to have a machine in your private network running the "local" provider. Obviously this is a bit sucky, because you then have to run all your juju commands from there, but it's an option until manual bootstrapping comes along.</div>
<div><br></div><div>I am in the process of implementing manual bootstrapping and a "null" provider. The null provider does nothing (surprised?) other than manage storage at the bootstrap node. The bootstrap node is created via manual bootstrapping. At least, that's how it is in my sandbox. This may change when it escapes :)<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">

<p>I don't know what the roadmap is like, but it seems like we should implement the manual provider as an actual provider with a type and everything that can live in your environments.yaml. For me, the ideal would be able to just specify a list of IP addresses in environments.yaml and make that my "cloud". MAAS is nice and all, but it's a lot of setup for a situation where I specifically do not want a lot of setup. I just want to be able to say "I have these three Ubuntu machines (specified by IP addresses), juju go do your thing". Minimum barrier of entry.  </p>
</div></blockquote><div>I have had similar thoughts of listing IPs, but it's probably not worthwhile. There'd be a bunch of work involved to store the dynamic set of IPs somewhere in state (environments.yaml isn't really suitable, it's static), and you'd *have* to have password-less ssh and sudo. The intention with the current approach is to be able to prime a machine with juju add-machine, and then later when you deploy a charm, juju will pick one of those machines.</div>
</div></div></div>