On 6 November 2013 01:23, Andrew Wilkins <andrew.wilk...@canonical.com> wrote:
> On Tue, Nov 5, 2013 at 6:22 PM, William Reade <william.re...@canonical.com>
> wrote:
>>
>> On Tue, Nov 5, 2013 at 10:25 AM, Andrew Wilkins
>> <andrew.wilk...@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.
>
>
> Sounds good. I was doing a literal translation, obviously.
>
>>>
>>> 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.
>
>
> Okay. I expected some sort of streaming/chunking would be required, just
> wanted to check assumptions before adding complexity.
FWIW I'm strongly in favour of *not* sending charms through
the RPC interface - it is likely not incur a significant performance
hit over a high latency connection. I don't *think* that implementing
a PUT handler on the API server should be too much of a problem.
>>> 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?)
>
>
> It feels a bit wrong to me to be doing formatting behind the API server
> (conflating data and presentation), but that would certainly make it
> simpler. The canonical format could be YAML (or JSON), though, and the
> consumer can convert that to whatever they like.
It seems wrong to me too. I suggest we send the format directly
over the wire in JSON format (we can use the struct type already
defined in StatusCommand.Run, with component types suitable
exported). The only problem we have sending JSON across the wire
is when we send interface{} values, and that struct does not contain
any of those, so I think it should Just Work.
cheers,
rog.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
