API access to Environ

[roger peppe]

On 15 February 2013 18:58, Gustavo Niemeyer
<gustavo.niemeyer at canonical.com> wrote:
> On Fri, Feb 15, 2013 at 4:52 PM, roger peppe <rogpeppe at gmail.com> wrote:
>> We want to give the GUI access to as much functionality
>> from the command line as we can.
>> Currently various commands make use of the Environ,
>> and currently the API server has no access to that.
>>
>> Off the top of my head, the commands that use the Environ are:
>>
>> bootstrap
>>    - This is the big one - we'd need some way of getting the GUI
>> to start a new instance running the required stuff. Thoughts
>> on the best way of accomplishing this (e.g. in-browser, provider-proxy)
>> are welcome!
>
> That looks like a chicken and egg issue. There's no API to talk to.
>
>> status
>>   - Status uses the environment to find out DNS names of instances.
>> We could add another worker that finds DNS names of
>> machine instances and sets them in the state.
>
> The provisioner might do it.
>
>> deploy
>>   - Deploy uses the environment storage to push charms. It has long
>> been the plan to use the state for charm storage rather than the environment,
>> and this is a good reason for it.
>
> This seems like a slightly different issue. The GUI should probably
> not push charms at all.
>
> For that kind of reason, it was always a goal to have the environment
> itself being able to pull the charms instead of requiring the client
> to send them.

Yes, I agree that the API server itself should pull charms
(apart from the local charm case, as Kapil points out),
but as I said, currently the API server doesn't have access
to an Environ, and in the long term, I don't think we want
it to. Maybe I'm wrong there though.

It can get one (in the same way as the ManageEnviron workers),
but as I was saying, that adds stuff that we probably
want to tear out later, and perhaps we'd be better off
if we made the API server upload charms to the state
rather than the environment.

  cheers,
    rog.