On 09/11/2014 05:01 PM, Jay Pipes wrote:
On 09/11/2014 04:51 PM, Matt Riedemann wrote:
On 9/10/2014 6:00 PM, Russell Bryant wrote:
On 09/10/2014 06:46 PM, Joe Cropper wrote:
Hmm, not sure I follow the concern, Russell. How is that any different
from putting a VM into the group when it’s
Le 11/09/2014 01:10, Joe Cropper a écrit :
Agreed - I’ll draft up a formal proposal in the next week or two and we can
focus the discussion there. Thanks for the feedback - this provides a good
framework for implementation considerations.
Count me on it, I'm interested in discussing the
Great to hear. I started a blueprint for this [1]. More detail can be added
once the kilo nova-specs directory is created… for now, I’ve tried to put some
fairly detailed notes on the blueprint’s description.
[1] https://blueprints.launchpad.net/nova/+spec/dynamic-server-groups
- Joe
On Sep
On 09/11/2014 04:51 PM, Matt Riedemann wrote:
On 9/10/2014 6:00 PM, Russell Bryant wrote:
On 09/10/2014 06:46 PM, Joe Cropper wrote:
Hmm, not sure I follow the concern, Russell. How is that any different
from putting a VM into the group when it’s booted as is done today?
This simply defers
On 09/11/2014 03:01 PM, Jay Pipes wrote:
On 09/11/2014 04:51 PM, Matt Riedemann wrote:
On 9/10/2014 6:00 PM, Russell Bryant wrote:
On 09/10/2014 06:46 PM, Joe Cropper wrote:
Hmm, not sure I follow the concern, Russell. How is that any different
from putting a VM into the group when it’s
I would be a little wary about the DB level locking for stuff like that — it’s
certainly doable, but also comes at the expense of things behaving
ever-so-slightly different from DBMS to DBMS. Perhaps there are multiple
“logical efforts” here—i.e., adding some APIs and cleaning up existing
I agree, Chris. I think a number of folks put in a lot of really great work
into the existing server groups and there has been a lot of interest on their
usage, especially given that the scheduler already has some constructs in place
to piggyback on them.
I would like to craft up a blueprint
On Sep 10, 2014, at 2:03 PM, Joe Cropper cropper@gmail.com wrote:
I agree, Chris. I think a number of folks put in a lot of really great work
into the existing server groups and there has been a lot of interest on their
usage, especially given that the scheduler already has some
Hmm, not sure I follow the concern, Russell. How is that any different from
putting a VM into the group when it’s booted as is done today? This simply
defers the ‘group insertion time’ to some time after initial the VM’s been
spawned, so I’m not sure this creates anymore race conditions than
On 09/10/2014 04:16 PM, Russell Bryant wrote:
On Sep 10, 2014, at 2:03 PM, Joe Cropper cropper@gmail.com
wrote:
I would like to craft up a blueprint proposal for Kilo to add two
simple extensions to the existing server group APIs that I believe
will make them infinitely more usable in
On 09/10/2014 06:46 PM, Joe Cropper wrote:
Hmm, not sure I follow the concern, Russell. How is that any different
from putting a VM into the group when it’s booted as is done today?
This simply defers the ‘group insertion time’ to some time after
initial the VM’s been spawned, so I’m not
+1, Chris.
I think the key thing here is that such race conditions can already happen if
timed just right, unless there’s been some additional checks put in place in
the compute API layer since I last scanned the code. We could even look at
some x-process locking mechanisms as well if we
Agreed - I’ll draft up a formal proposal in the next week or two and we can
focus the discussion there. Thanks for the feedback - this provides a good
framework for implementation considerations.
- Joe
On Sep 10, 2014, at 6:00 PM, Russell Bryant rbry...@redhat.com wrote:
On 09/10/2014 06:46
On 08/25/2014 11:25 AM, Joe Cropper wrote:
I was thinking something simple such as only allowing the add
operation to succeed IFF no policies are found to be in violation...
and then nova wouldn't need to get into all the complexities you
mention?
Personally I would be in favour of
Hello,
Is our long-term vision to allow a VMs to be dynamically added/removed
from a group? That is, unless I'm overlooking something, it appears
that you can only add a VM to a server group at VM boot time and
effectively remove it by deleting the VM?
Just curious if this was a design point,
On 08/25/2014 11:10 AM, Joe Cropper wrote:
Hello,
Is our long-term vision to allow a VMs to be dynamically added/removed
from a group? That is, unless I'm overlooking something, it appears
that you can only add a VM to a server group at VM boot time and
effectively remove it by deleting the
Thanks Jay. Those are the same types of questions I was pondering as
well when debating how someone might use this. I think what we have
is fine for a first pass, but that's what I was poking at... whether
some of the abilities to add/remove members dynamically could exist
(e.g., I no longer
On 08/25/2014 11:31 AM, Joe Cropper wrote:
Thanks Jay. Those are the same types of questions I was pondering as
well when debating how someone might use this. I think what we have
is fine for a first pass, but that's what I was poking at... whether
some of the abilities to add/remove members
That was indeed a rather long (and insightful) thread on the topic.
It sounds like there are still some healthy discussions worth having
on the subject -- either exploring your [potentially superseding]
proposal, or minimally rounding out the existing server group API to
support add existing VM
On 08/25/2014 12:56 PM, Joe Cropper wrote:
That was indeed a rather long (and insightful) thread on the topic.
It sounds like there are still some healthy discussions worth having
on the subject -- either exploring your [potentially superseding]
proposal, or minimally rounding out the existing
I was thinking something simple such as only allowing the add operation to
succeed IFF no policies are found to be in violation... and then nova wouldn't
need to get into all the complexities you mention?
And remove would be fairly straightforward as well since no constraints would
need to be
On 08/25/2014 01:25 PM, Joe Cropper wrote:
I was thinking something simple such as only allowing the add operation to
succeed IFF no policies are found to be in violation... and then nova
wouldn't need to get into all the complexities you mention?
Even something like this is a lot more
Even something like this is a lot more complicated than it sounds due to
the fact that several operations can be happening in parallel.
That's fair, but I was thinking that the 'add existing' VM is fairly
close in behavior to 'add new' VM to the group, less of course any
parallel operations
23 matches
Mail list logo
