Hi Sylvain,
I would go with keeping AZs exclusive. It is a well-established concept even if
it is up to providers to implement what it actually means in terms of
isolation. Some good use cases have been presented on this topic recently, but
for me they suggest we should develop a better
for blueprints). But now I am referring
to another thread
[http://lists.openstack.org/pipermail/openstack-dev/2014-March/029232.html ]
Paul.
-Original Message-
From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
Sent: 04 March 2014 21:25
To: Murray, Paul (HP Cloud Services)
Cc
The principle is excellent, I think there are two points/objectives worth
keeping in mind:
1. We need an effective way to make and record the design decisions
2. We should make the whole development process easier
In my mind the point of the design review part is to agree up front something
Hi All,
One of my patches has a query asking if I am using the agreed way to load
plugins: https://review.openstack.org/#/c/71557/
I followed the same approach as filters/weights/metrics using nova.loadables.
Was there an agreement to do it a different way? And if so, what is the agreed
way
March 2014 17:50
To: OpenStack Development Mailing List (not for usage questions); Murray, Paul
(HP Cloud Services)
Subject: RE: [openstack-dev] [Nova] What is the currently accepted way to do
plugins
This brings up something that's been gnawing at me for a while now ... why use
entry-point based
, but I think I
can get on with it.
Paul.
-Original Message-
From: Dan Smith [mailto:d...@danplanet.com]
Sent: 03 February 2014 20:59
To: Murray, Paul (HP Cloud Services); OpenStack Development Mailing List (not
for usage questions)
Subject: Re: [Nova] do nova objects work for plugins
Hi Sahid,
This is being done by Oshrit Feder, so I'll let her answer, but I know that it
is going to be implemented as an extensible resource (see:
https://blueprints.launchpad.net/nova/+spec/extensible-resource-tracking) so it
is waiting for that to be done. That blueprint is making good
I was looking through Nova Objects with a view to creating an extensible object
that can be used by writers of plugins to include data generated by the plugin
(others have also done the same e.g. https://review.openstack.org/#/c/65826/ )
On the way I noticed what I think is a bug in Nova
Hi,
I have heard a couple of conflicting comments about the scheduler and nova
objects that I would like to clear up. In one scheduler/gantt meeting, Gary
Kotton offered to convert the scheduler to use Nova objects. In another I heard
that with the creation of Gantt, the scheduler would avoid
Barbara [mailto:jus...@fathomdb.com]
Sent: 24 January 2014 21:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances
through metadata service
Murray, Paul (HP Cloud Services) wrote:
Multicast is not generally
Hi Justin,
It's nice to see someone bringing this kind of thing up. Seeding discovery is a
handy primitive to have.
Multicast is not generally used over the internet, so the comment about
removing multicast is not really justified, and any of the approaches that work
there could be used.
To be clear - the changes that Yunhong describes below are not part of the
extensible-resource-tracking blueprint. Extensible-resource-tracking has the
more modest aim to provide plugins to track additional resource data.
Paul.
-Original Message-
From: Jiang, Yunhong
you see these belonging here or would you expect those to go in a sub-class
if they were wanted?
Paul.
-Original Message-
From: Dan Smith [mailto:d...@danplanet.com]
Sent: 10 January 2014 16:22
To: Murray, Paul (HP Cloud Services); Wang, Shane; OpenStack Development
Mailing List
happy with your dirty children :)
Paul.
-Original Message-
From: Dan Smith [mailto:d...@danplanet.com]
Sent: 13 January 2014 15:26
To: Murray, Paul (HP Cloud Services); Wang, Shane; OpenStack Development
Mailing List (not for usage questions)
Cc: Lee, Alexis; Tan, Lin
Subject: Re: [Nova
work to allow the changes and to track
them there too.
Paul.
-Original Message-
From: Dan Smith [mailto:d...@danplanet.com]
Sent: 10 January 2014 14:42
To: Wang, Shane; OpenStack Development Mailing List (not for usage questions)
Cc: Murray, Paul (HP Cloud Services); Lee, Alexis; Tan
Hi Abbass,
I guess you read the blueprint Russell referred to. I think you actually are
saying the same - but please read steps below and tell me if they don't cover
what you want.
This is what it will do:
1. Add a column to the compute_nodes table for a JSON blob
2. Add plug-in
Hi Abbass,
I am in the process of coding some of this now - take a look at
https://blueprints.launchpad.net/nova/+spec/extensible-resource-tracking - now
has a specification document attached
https://etherpad.openstack.org/p/IcehouseNovaExtensibleSchedulerMetrics - the
design summit session
Hi Sean,
Do you think the existing static allocators should be migrated to going through
ceilometer - or do you see that as different? Ignoring backward compatibility.
The reason I ask is I want to extend the static allocators to include a couple
more. These plugins are the way I would have
[mailto:s...@dague.net]
Sent: 19 July 2013 14:28
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics
collector for scheduling
On 07/19/2013 08:30 AM, Andrew Laski wrote:
On 07/19/13 at 12:08pm, Murray, Paul (HP Cloud Services) wrote:
Hi Sean
Hi All,
I would like to chip in with something from the side here (sorry to stretch the
discussion out).
I was looking for a mechanism to do something like this in the context of this
blueprint on network aware scheduling:
to me.
BTW, I'm getting all the other emails - just not this thread!
Bemused...
Paul
On 07/18/2013 10:44 AM, Murray, Paul (HP Cloud Services) wrote:
Hi All,
I would like to chip in with something from the side here (sorry to stretch
the discussion out).
I was looking for a mechanism to do
21 matches
Mail list logo
