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,
On Wed, Nov 6, 2013 at 1:49 PM, roger peppe rogpe...@gmail.com 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
-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
-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, working
On 6 November 2013 14:29, John Arbash Meinel j...@arbash-meinel.com 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
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 current plan is to have a single juju ensure-ha-state juju
command. This would create new state server machines if there are less
than the required number (currently 3).
Taking that as given, I'm wondering what we should do
in the future, when users require more than a single
big On switch
just my tuppence...
Would it not be clearer to add an additional command to implement your
proposal? E.g. add-manager and possibly destroy/remove-manager
This could also support switches for later fine control, and possibly
be less open to misinterpretation than overloading the add-machine
The answer to how does the user know how to X? is the same as it always
has been. Documentation. Now, that's not to say that we still don't need
to do some work to make it intuitive... but I think that for something that
is complicated like HA, leaning on documentation a little more is ok.
More
Oops, missed the end of a thought there. If we get to the point of needing
more than 12 server nodes (not unfathomable), then we have to start doing
some more work for our hyperscale customers, which will probably involve
much more customization and require much more knowledge of the system.
I
On Thu, Nov 7, 2013 at 2:49 AM, roger peppe rogpe...@gmail.com wrote:
The current plan is to have a single juju ensure-ha-state juju
command. This would create new state server machines if there are less
than the required number (currently 3).
Taking that as given, I'm wondering what we
On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth ian.bo...@canonical.com wrote:
So, I haven't been involved directly in a lot of the discussion, but my 2c
is:
+1 to juju ensure-ha
Users don't give a f*ck about how Juju achieves HA, they just want to know
their
data will survive a node outage.
On 07/11/13 15:00, Andrew Wilkins wrote:
On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth ian.bo...@canonical.com
mailto:ian.bo...@canonical.com wrote:
So, I haven't been involved directly in a lot of the discussion, but
my 2c is:
+1 to juju ensure-ha
Users don't give a f*ck
Hi guys,
I'm glad j...@lists.ubuntu.com got accidentally looped in because I may not
have caught wind of this. I can understand both sides of the discussion,
one where we provide more magic and the users trust that it works and the
other where we leverage existing components and command
Howdy from OpenStack Hong Kong everyone.
Some of you may be aware that MidoKura is working on JuJu support for our SDN
virtual network. On that front, I have a question for consideration.
Since networking isn’t really a straightforward “component” of OpenStack that
fits nicely inside a box, I
15 matches
Mail list logo
