For a little further exposition of the issue, here's a branch
that implements the API server side of charm streaming
as I'm suggesting. It seems reasonably simple to me.
https://codereview.appspot.com/22100045/
To complete this, we'd need an implementation of State.PutCharmBundle
that streams the
On 6 November 2013 14:29, John Arbash Meinel wrote:
>>> I would be perfectly happy with PUT if we were already a RESTful
>>> API, but it seems a bit strange to just tack that on, and will be
>>> a one-more-special case that we run into when trying to debug,
>>> etc. (logs will likely be different,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
>>
>> I would be perfectly happy with PUT if we were already a RESTful
>> API, but it seems a bit strange to just tack that on, and will be
>> a one-more-special case that we run into when trying to debug,
>> etc. (logs will likely be different,
On 6 November 2013 13:59, John Arbash Meinel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> ...
>>
>> Long term, I'd like to deprecate the root as a way of talking to
>> the API and mandate (for instance) /api as a URL path. Short term,
>> we can't do that, but we *can* treat, for in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
>
> Long term, I'd like to deprecate the root as a way of talking to
> the API and mandate (for instance) /api as a URL path. Short term,
> we can't do that, but we *can* treat, for instance /charm
> differently and serve PUT (and potentially GET
On 6 November 2013 13:30, William Reade wrote:
> On Wed, Nov 6, 2013 at 1:49 PM, roger peppe wrote:
>>
>> 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
On Wed, Nov 6, 2013 at 1:49 PM, roger peppe wrote:
> 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
On 6 November 2013 01:23, Andrew Wilkins wrote:
> On Tue, Nov 5, 2013 at 6:22 PM, William Reade
> wrote:
>>
>> On Tue, Nov 5, 2013 at 10:25 AM, Andrew Wilkins
>> wrote:
>>>
>>> As I've been looking for things to bite off, here's some comments from me
>>> (excluding things others are already look
On Tue, Nov 5, 2013 at 6:22 PM, William Reade
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:
Thank you for the updates, Andrew. When you have a chance, would you mind
talking with me about debug-log, uploading a charm, and the associated
changes to deploy and upgrade-charm? The GUI definitely cares about those
and I'd like to make sure we have talked through the design to make sure we
can
On Tue, Nov 5, 2013 at 4:25 AM, Andrew Wilkins wrote:
> I thought I'd summarise where things are at now, in case anyone else
> starts looking for work to do. Ignoring the DONE's, we have the following
> remaining (see below for commentary):
>
> api-endpoints: TODO
> [axwalk] debug-hooks: INPROGRE
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 n
> > status: haven't looked into in detail, looks like a big task.
> > don't forget filters :)
>
> Well, we don't support filters today, so we don't have to do all the
> design in the first pass.
>
We do - I added it to fix a pyjuju parity bug. It shouldn't be difficult to
handle, anyway.
Cheers,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
> api-endpoints: (I don't recall why we put this in the list at all?
> What needs to be done here?)
"juju api-endpoints" is a CLI command, seems like it should use
APIAddresses via the API so that it can return all possible API servers.
>
> up
I thought I'd summarise where things are at now, in case anyone else starts
looking for work to do. Ignoring the DONE's, we have the following
remaining (see below for commentary):
api-endpoints: TODO
[axwalk] debug-hooks: INPROGRESS
[axwalk] debug-log: INPROGRESS
deploy: TODO
destroy-environment:
-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 b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-11-04 0:45, Tim Penhey wrote:
> On 02/11/13 03:32, Kapil Thangavelu wrote:
>> I'd suggest creating a bug per command (some already have extant
>> bugs), there's vastly differing amounts of work in them, and its
>> easier to track progress with
On 02/11/13 03:32, Kapil Thangavelu wrote:
> I'd suggest creating a bug per command (some already have extant bugs),
> there's vastly differing amounts of work in them, and its easier to
> track progress with appropriately sized tasks. ie kanban style cli api
> is a story.
As discussed at the spri
've created a bug to do the CLI->API work. If there's something existing,
> or a more appropriate place to do this, let me know and this can disappear.
>
> https://bugs.launchpad.net/juju-core/+bug/1246983
>
> I'm going to look at doing destroy-machine, wh
I've created a bug to do the CLI->API work. If there's something existing,
or a more appropriate place to do this, let me know and this can disappear.
https://bugs.launchpad.net/juju-core/+bug/1246983
I'm going to look at doing destroy-machine, which looks pretty trivia
20 matches
Mail list logo
