API work

Tue Nov 5 10:22:25 UTC 2013

On Tue, Nov 5, 2013 at 10:25 AM, Andrew Wilkins <
andrew.wilkins at canonical.com> wrote:

> As I've been looking for things to bite off, here's some comments from me
> (excluding things others are already looking into).
>
> api-endpoints:
>   (I don't recall why we put this in the list at all? What needs to be
> done here?)
>

Connect to the API, find out if there are any addresses we didn't already
know about. Every command should be updating the local endpoints cache
anyway so Idon't think it needs to do anything but connect and stop.

> upgrade-juju:
>     this requires get/set-environment
>

Get maybe, but we really shouldn't use set-environment for this -- allowing
the set-environment path to change agent-version is a Bad Idea because it's
an automatic end-run around any upgrade sanity we ever impose. I'd really
favour explicitly matched api calls for get/set of agent-version.

> deploy, upgrade-charm:
>     These require some way of uploading charms. By the way, what's our
> maximum size for charms, and for RPC messages?
>

If there's a max rpc message size, there will be charms that are larger. If
there isn't, there should be.

> status:
>     haven't looked into in detail, looks like a big task. don't forget
> filters :)
>

So, there's some stupid stuff that needs to be fixed (talking to the
provider to find out about every single instance was fine for a while, but
we're way past the point where it scales sanely)... but I don't see any
serious problem with basically just passing the args over and returning the
requested format in a single string value. (I don't think we really want to
try to pass it over as structured data, because I'm not very optimistic
about the impact of jamming our structs through a json-shaped hole before
rendering them as yaml. Maybe I'm wrong there?)

> destroy-environment:
>     I'm told we can destroy-environment from within an environment, but
> that sounds perilous to me. At any rate, we need to make some changes here
> to accommodate manually provisioned machines inside non-manual provider
> environments (when we support that), and cleanly destroying manual-provider
> environments by enumerating/destroying state entities.
>

We can fix the manual stuff as a first step; that's definitely required
regardless. What's the status on manually provisioned machines inside
normal environments? I didn't think we *disallowed* it -- we just
discourage it on the basis that it's unlikely to be useful in most cases --
but there are reasonable use cases, I think.

> debug-hooks, debug-log, scp and ssh:
>     I'm working on these, and have them mostly done. I've added two new
> client API calls: ServiceEndpoints, and PublicAddress (perhaps this ought
> to be Addresses?), which takes a unit or machine ID and returns its public
> address.
>

What does ServiceEndpoints do?

>     There's a remaining problem in that API connections do not push
> secrets to the API server. This means the server can't get an Environ,
> which means the address updater can't do its stuff.
>

And nor can the provisioner or firewaller, or even important parts of the
api server itself. So, yeah, this needs to be fixed. On balance I'm +1 on a
quick and somewhat dirty repeat of the secrets dance in api.Open (as
suggested by roger) so long as we don't spend too long on it; but gating
further cli api progress on tim's bootstrap changes is likely to be a Bad
Idea.

>
> Cheers,
> Andrew
>
>
> On Tue, Nov 5, 2013 at 3:41 AM, Tim Penhey <tim.penhey at canonical.com>wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 05/11/13 00:45, John Arbash Meinel wrote:
>> >> https://blueprints.launchpad.net/juju-core/+spec/t-cloud-juju-cli-api
>> >
>> >>  I also went through the photo I took of our big bit of paper
>> >> and marked done those that were (although sync-tools seemed to be
>> >> a bit edgy).
>> >
>> > Can you at least link the image to the blueprint so we can see the
>> > Size information for each item?
>>
>> Done. Description now links to this image:
>>
>> http://people.canonical.com/~tim/api-cli.jpg
>>
>>
>> I have also subscribed some of you to the blueprint. This means that
>> you'll get emails when someone edits the work items.
>>
>> Please note that since multiple people are editing the work items at
>> one time, it is possible that there is a race condition on the updates
>> (hence it is good to get the email), and this race window is much
>> larger if you have stale data in your web browser.
>>
>> I've seen at least one it happen where someone else's work items have
>> been cleared out accidentally.  Please double check that this is up to
>> date with what you are doing.
>>
>> Cheers,
>> Tim
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.14 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iEYEARECAAYFAlJ3+FkACgkQd1fvI4G7WRBGywCfczJJB0O41IBJYQ9Ir/bajKci
>> bI4AoLSaf5uiOrGsob5CO/JiW5UUJsB+
>> =J05Q
>> -----END PGP SIGNATURE-----
>>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20131105/c8bf9406/attachment-0001.html>