On 11/15/2013 12:01 PM, Mark McLoughlin wrote:
On Fri, 2013-11-15 at 11:28 -0500, Russell Bryant wrote:
Greetings,
We've talked a lot about requirements for new compute drivers [1]. I
think the same sort of standards shold be applied for a new third-party
API, such as the GCE API [2
this sort of requirement acceptable in our
community.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
in Nova. There is
certainly interest. I've followed up with Rohit who led the session at
the design summit and we should see a sub-team ramping up soon. The
things we talked about the sub-team focusing on are in-line with moving
toward meeting this bar, anyway.
--
Russell Bryant
matters.
That's my suggestion. Focus on what matters (future of Neutron) and not
clothing requirements. Retract all of that from the sprint announcement
and then perhaps we can do so. :-)
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack
/icehouse-summit-qa-neutron
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
MechanismDrivers as well.
A bit of a terminology nit ... SmokeStack is a specific system that runs
tests and reports results back to gerrit. Presumably the requirement is
to be *like* SmokeStack, but not be integrated with SmokeStack itself.
--
Russell Bryant
://lists.openstack.org/pipermail/openstack-dev/2013-October/016661.html
I don't think we need a blueprint.
Yes, I would list it under group C and add a column for it.
Is there any chance you would be interested in working on setting up CI
for it?
--
Russell Bryant
Most projects follow a review rule that a patch needs 2 +2s before being
approved. I suggest we do the same for Solum. I bring it up since I've
noticed some inconsistency with this so far.
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
to wait for
every third party system to report in before merging the patch.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 11/18/2013 09:55 AM, Álvaro López García wrote:
On Sat 16 Nov 2013 (17:43), Russell Bryant wrote:
On 11/16/2013 11:18 AM, Álvaro López García wrote:
On Fri 15 Nov 2013 (07:28), Dan Smith wrote:
Hi all,
Hi Dan.
As you know, Nova adopted a plan to require CI testing for all our
in-tree
with broad
expertise to help out.
For more information on the vulnerability management process, see [2].
Who's in?
[1] https://launchpad.net/~nova-coresec
[2] https://wiki.openstack.org/wiki/Vulnerability_Management
--
Russell Bryant
___
OpenStack-dev mailing
with the current scope
of Nova. I also expect a lot of innovation around containers in the
next few years, which will result in wanting to do new cool things in
the API. I feel that all of this justifies a new API service to best
position ourselves for the long term.
--
Russell Bryant
access to compute resources,
including both virtual machines and containers.
[1]
http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
On 11/18/2013 07:58 PM, Krishna Raman wrote:
I have also set up a doodle poll
at http://doodle.com/w7y5qcdvq9i36757 to gather a times when a majority
of us are available to discuss on IRC.
What time zone are these times in?
--
Russell Bryant
On 11/19/2013 12:01 AM, Krishna Raman wrote:
On Nov 18, 2013, at 5:52 PM, Russell Bryant rbry...@redhat.com wrote:
Greetings,
Every OpenStack program is supposed to have a mission statement. The
Compute program does not have one yet [1]. Here is a first attempt at
it. Let me know what
to define clearly. I would appreciate input on how we can define it
more cleanly so that it can be enforced by the blueprint reviewers
consistently.
Thanks,
[1] https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria
--
Russell Bryant
On 11/19/2013 11:11 AM, Daniel P. Berrange wrote:
On Tue, Nov 19, 2013 at 10:56:10AM -0500, Russell Bryant wrote:
Greetings,
One of the bits of feedback that came from the Nova Project Structure
and Process session at the design summit was that it would be nice to
skip having blueprints
against.
Even if this ends up staying in Nova, the API work is still useful. It
would help us toward defining a container specific extension to the
compute API.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 11/20/2013 05:37 AM, Daniel P. Berrange wrote:
On Wed, Nov 20, 2013 at 11:21:14AM +0100, Thierry Carrez wrote:
Russell Bryant wrote:
One of the bits of feedback that came from the Nova Project Structure
and Process session at the design summit was that it would be nice to
skip having
for this. This produces the expected output.
http://paste.openstack.org/show/53687/
https://git.openstack.org/cgit/openstack/nova/tree/nova/openstack/common/local.py
For reference, original example from OP:
http://paste.openstack.org/show/53686/
--
Russell Bryant
-August/013992.html
[2] https://review.openstack.org/#/c/37913/
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
this driver until you were
able to go the libvirt route.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
that approach quite a bit.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
...
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
turns
in to a regular thing, we should probably switch it to some sort of
sub-team type name ... like nova-containers.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
and has
earned the trust of other members of the review team.
https://review.openstack.org/#/dashboard/6873
https://review.openstack.org/#/q/owner:6873,n,z
https://review.openstack.org/#/q/reviewer:6873,n,z
Please respond with +1/-1, or any further comments.
Thanks,
--
Russell Bryant
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
if the options that enable this come with a giant warning,
it'd be OK. Something like:
WARNING: Using this option changes how Nova uses the eventlet
library to support async IO. This could result in failures that do
not occur under normal opreation. Use at your own risk.
--
Russell Bryant
On 11/22/2013 09:07 PM, Matt Riedemann wrote:
On Friday, November 22, 2013 5:52:17 PM, Russell Bryant wrote:
On 11/22/2013 06:01 PM, Christopher Yeoh wrote:
On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote
Greetings,
Since Thursday this week is a holiday in the US, we will skip the Nova
meeting. We'll meet again next week.
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
in a driver. I think we've let some drivers in with far
too many features not supported. That's a separate issue from the CI
requirement, though.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
On 11/25/2013 08:00 PM, Matt Riedemann wrote:
On Monday, November 25, 2013 4:37:29 PM, Russell Bryant wrote:
I think the short answer is, whatever we're running against all Nova
changes in the gate.
Maybe a silly question, but is what is run against the check queue any
different from
configure their own
flavors for a production deployment anyway.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 11/26/2013 04:48 AM, Bob Ball wrote:
-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com]
Sent: 25 November 2013 22:37
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
deprecation plan
On 11/25/2013 05:19 PM
On 11/26/2013 09:38 AM, Bob Ball wrote:
-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com]
Sent: 26 November 2013 13:56
To: openstack-dev@lists.openstack.org
Cc: Sean Dague
Subject: Re: [openstack-dev] [Nova] Hypervisor CI requirement and
deprecation plan
On 11/26
-30.txt
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to be just as complex as organizing the design summit itself.
These events really should be seen as optional, especially as compared
to the regular design summit. Traveling twice a year just for the
regular design summits is a lot for many. So, don't stress if you can't
make it.
--
Russell Bryant
, and will
greatly help the stable-maintainers team.
I will add these responsibilities to the review checklist[2] unless
I hear some disagreement here.
+1
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
On 11/26/2013 02:32 PM, Russell Bryant wrote:
Greetings,
I would like to propose that we re-add Dan Prince to the nova-core
review team.
Dan Prince has been involved with Nova since early in OpenStack's
history (Bexar timeframe). He was a member of the nova-core review team
from May
On 11/22/2013 03:53 PM, Russell Bryant wrote:
Greetings,
I would like to propose adding Matt Riedemann to the nova-core review team.
Matt has been involved with nova for a long time, taking on a wide range
of tasks. He writes good code. He's very engaged with the development
community
, to include or not include the keystone middleware.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, though.
https://review.openstack.org/59367
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
a good idea.
[1] https://review.openstack.org/#/c/58668/
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to replace the one in the pecan config and that we
just overlooked doing that. It will certainly happen before any of that
app code makes it way into Oslo (planned for this cycle).
Alright, sounds good to me. Thanks!
--
Russell Bryant
___
OpenStack
On 12/02/2013 08:53 AM, Doug Hellmann wrote:
On Mon, Dec 2, 2013 at 8:46 AM, Doug Hellmann
doug.hellm...@dreamhost.com mailto:doug.hellm...@dreamhost.com wrote:
On Mon, Dec 2, 2013 at 8:36 AM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote
don't remove it completely. Putting it in oslo-incubator for now
seems fine, though.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
be integrated into it, the
project is ready to be integrated. Adding support for even more
projects is something that will continue to happen over a longer period
of time, I suspect, especially since new projects are coming in every cycle.
--
Russell Bryant
On 12/02/2013 09:51 AM, Andrew Laski wrote:
On 12/02/13 at 09:08am, Russell Bryant wrote:
On 12/02/2013 09:02 AM, Victor Sergeyev wrote:
Hi folks!
At the moment I and Roman Podoliaka are working on splitting of
openstack.common.db code into a separate library. And it would be nice
to drop
*after* the forklift. Will we have other
services integrated? Will it have its own database? How different is
different enough to warrant needing a deprecation cycle?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
supported live
upgrades in a CD environment.
I need to go back and add a shim layer that can handle receiving the
latest version of messages sent by Havana to all APIs.
[1] https://review.openstack.org/#/c/12130/
[2] https://review.openstack.org/#/c/12131/
--
Russell Bryant
On 12/02/2013 10:53 AM, Gary Kotton wrote:
On 12/2/13 5:39 PM, Russell Bryant rbry...@redhat.com wrote:
On 12/02/2013 10:33 AM, Monty Taylor wrote:
Just because I'd like to argue - if what we do here is an actual
forklift, do we really need a cycle of deprecation?
The reason I ask
Russell Bryant rbry...@redhat.com
1 Bryan D. Payne bdpa...@acm.org
It appears to be an effort done by a group, and not an individual. Most
commits by far are from Rackspace, but there is at least one non-trivial
contributor (Malini) from another company (Intel), so I think this is OK
On 12/02/2013 11:53 AM, Russell Bryant wrote:
** Project must have no library dependencies which effectively restrict how
the project may be distributed [1]
http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires
It looks like the only item here not in the global
with a variable that I can use ?
Don't add this. :-)
There is work in progress to just have a column with a json blob in it
for additional metadata like this.
https://blueprints.launchpad.net/nova/+spec/extensible-resource-tracking
https://wiki.openstack.org/wiki/ExtensibleResourceTracking
--
Russell
had it done and
working. Perhaps we should just revisit the deprecation plan once we
actually have the thing split out and running.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
by making these things a prerequisite.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 12/02/2013 12:46 PM, Monty Taylor wrote:
On 12/02/2013 11:53 AM, Russell Bryant wrote:
* Scope
** Project must have a clear and defined scope
This is missing
** Project should not inadvertently duplicate functionality present in
other
OpenStack projects. If they do, they should
On 12/02/2013 03:31 PM, Vishvananda Ishaya wrote:
On Dec 2, 2013, at 9:12 AM, Russell Bryant rbry...@redhat.com
wrote:
On 12/02/2013 10:59 AM, Gary Kotton wrote:
I think that this is certainly different. It is something that
we we want and need a user facing API. Examples: - aggregates
On 12/02/2013 06:46 PM, Dolph Mathews wrote:
On Mon, Dec 2, 2013 at 11:55 AM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
On 12/02/2013 12:46 PM, Monty Taylor wrote:
On 12/02/2013 11:53 AM, Russell Bryant wrote:
* Scope
** Project must have
. Names shouldn't
have to be globally unique (because of multi-tenancy). UUIDs should
always work, but you can support a name in the client code as a friendly
shortcut, but it should fail if a unique result can not be resolved from
the name.
--
Russell Bryant
://blueprints.launchpad.net/solum/+spec/solum-minimal-cli
Spec for the minimal CLI @
https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/CLI-minimal-implementation
Etherpad for discussion notes: https://etherpad.openstack.org/p/MinimalCLI
--
Russell Bryant
don't have the
messiness of the scheduler talking to multiple db apis.
+1
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
is the approach we should take. This is mainly
because there is common information that is needed for the scheduling
logic for resources in multiple projects.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
it
looks like this request should be deferred a bit longer.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
positional arguments.
Correct.
Optional still in the form --foo=bar
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 12/03/2013 01:26 PM, Russell Bryant wrote:
Unless the requirements change, so far it
looks like this request should be deferred a bit longer.
And note that this is just my opinion, and note a statement of position
on behalf of the entire TC. We can still officially consider the
request
on spellcheck of code and commit messages? :-)
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
if it has been now:))
I approved it.
https://blueprints.launchpad.net/nova/+spec/forklift-scheduler-breakout
Once this is moving, please keep me in the loop on progress.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
on the driver, you've met one of the most difficult requirments
to being in Nova.
Someone may also want to have a driver separate for control reasons.
I'd be surprised if that was really a factor with this particular
driver, though.
--
Russell Bryant
of nice improvements have been
made to WSME to remove technical boundaries to WSME adoption in Nova.
At this point, it's just a bandwidth issue AFAIK.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
couldn't even read your message..
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
.
FWIW, the conflict in this case was the Icehouse release schedule
coordination session, which is pretty much a requirement for all PTLs.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
of implementation time.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
one. It just gets you bonus imaginary internet points.
Requiring mock for new tests seems fine. We can grant exceptions in
specific cases if necessary. In general, we should be using mock for
new tests.
--
Russell Bryant
___
OpenStack-dev mailing
,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
]
(filesystem aaS) seems to be the closest thing. Perhaps some work in
Manila and some Nova+Manila integration would be the right direction here.
Thoughts?
[1] https://wiki.openstack.org/wiki/Manila_Overview
--
Russell Bryant
___
OpenStack-dev mailing
has a significant ongoing maintenance
impact. I'm assuming that the submitters are willing to help maintain
the code. We also need commitment from some subset of nova-core to
review this code.
So, what do folks from nova-core think? Are you on board with
maintaining this API?
--
Russell Bryant
,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
by others and then suggest them for -core membership.
Agreed here, as well. While the stats provide some important insight,
it's far from the whole picture.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
-subscribe stuff we need built in necessarily. Surely that has
been done multiple times by others already, though. We could build it
too, if we had to.
Can you (or someone) elaborate further on what will make this solution
superior to our existing options?
Thanks,
--
Russell Bryant
a reasonable plan to me!
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
?”
+1 for consistency.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 06/13/2014 06:40 PM, Michael Still wrote:
Greetings,
I would like to nominate Ken'ichi Ohmichi for the nova-core team.
+1
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
sounds good to me. Thanks for writing it up!
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references
Seems reasonable to me.
Of course, I just hope it doesn't put reviewers in a mode of only
looking for the trivial stuff and helping less with the big stuff.
--
Russell Bryant
/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Russell Bryant
___
OpenStack-dev
it. Although I
wouldn't necessarily recommend it. In almost all cases where someone
wants to shrink a disk, IMHO it is better to sparsify it instead
(ie. virt-sparsify).
FWIW, the resize operation in OpenStack is a dead one.
--
Russell Bryant
___
OpenStack
make the more important bugs and blueprints even *harder*
to get done.
In the end, as others have said, the biggest problem by far is just that
we need more of the right people reviewing code.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack
sets would skew the patches side.
Trivial rebase detection skews the reviews received side. It was just
a mess.
[1] http://git.openstack.org/cgit/openstack-infra/reviewstats
[2] http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
--
Russell Bryant
specs whenever.
Expectations just need to be set appropriately that it may be a while
before they get reviewed/approved.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
On 06/24/2014 08:56 AM, Anne Gentle wrote:
On Tue, Jun 24, 2014 at 7:07 AM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
On 06/24/2014 07:35 AM, Michael Still wrote:
Phil -- I really want people to focus their efforts on fixing bugs in
that period
to make sure it's *completely* dead before taking further
action such as evacuating the host. You certainly don't want to risk
having the VM running on two different hosts. This is just a business I
don't think Nova should be getting in to.
--
Russell Bryant
%) |
|wingwj | 10 0 1 0 0 100.0% |
0 ( 0.0%) |
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 07/01/2014 05:59 PM, Adrian Otto wrote:
Team,
Please help us select dates for the Containers Team Midcycle Meetup:
http://doodle.com/2mebqhdxpksf763m
Why not just join the Nova meetup?
--
Russell Bryant
___
OpenStack-dev mailing list
go at it again without finishing the job first.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
needs to fail if a legacy groups exists with the same name ?
Sounds like a reasonable set of improvements to me.
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
Historically, at least with Nova, the current PTL has done the
novaclient releases. I'm happy to do it though if Michael is OK with it
(CC'd).
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
. be moved. What
is the interface between Nova and the scheduler here?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
reverts are needed.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
301 - 400 of 779 matches
Mail list logo
