<br><br><div class="gmail_quote">On Fri, Feb 15, 2013 at 12:58 PM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Feb 15, 2013 at 4:52 PM, roger peppe <<a href="mailto:rogpeppe@gmail.com">rogpeppe@gmail.com</a>> wrote:<br>

> We want to give the GUI access to as much functionality<br>
> from the command line as we can.<br>
> Currently various commands make use of the Environ,<br>
> and currently the API server has no access to that.<br>
><br>
> Off the top of my head, the commands that use the Environ are:<br>
><br>
> bootstrap<br>
>    - This is the big one - we'd need some way of getting the GUI<br>
> to start a new instance running the required stuff. Thoughts<br>
> on the best way of accomplishing this (e.g. in-browser, provider-proxy)<br>
> are welcome!<br>
<br>
</div>That looks like a chicken and egg issue. There's no API to talk to.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Not sure that this one needs to be tackled now. One nice consequence of the gui deployed as a charm means creds/env settings are done.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> status<br>
>   - Status uses the environment to find out DNS names of instances.<br>
> We could add another worker that finds DNS names of<br>
> machine instances and sets them in the state.<br>
<br>
</div>The provisioner might do it.<br>
<div class="im"><br>
> deploy<br>
>   - Deploy uses the environment storage to push charms. It has long<br>
> been the plan to use the state for charm storage rather than the environment,<br>
> and this is a good reason for it.<br>
<br>
</div>This seems like a slightly different issue. The GUI should probably<br>
not push charms at all.<br>
<br>
For that kind of reason, it was always a goal to have the environment<br>
itself being able to pull the charms instead of requiring the client<br>
to send them.<br></blockquote><div><br></div><div>That's currently what the pyju api server does as well (env downloads from store), but the question still arises in the context of local charm support.</div><div> </div>
<div>cheers,</div><div><br></div><div>kapil</div></div>