=novadocker.virt.docker.driver.DockerDriver
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 03/12/2014 08:02 AM, Sean Dague wrote:
On 03/12/2014 07:36 AM, Russell Bryant wrote:
Note that devstack is going to break for docker and Nova master
right now. We're in the middle of moving the docker driver. In
the meantime, use a rev of Nova before this merge:
https
of
code to ease implementing this sort of thing in each API that needs it.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 03/12/2014 12:14 PM, Sylvain Bauza wrote:
Hi Russell,
Thanks for replying,
2014-03-12 16:46 GMT+01:00 Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com:
The biggest concern seemed to be that we weren't sure whether Climate
makes sense as an independent project
has to be on high/critical priority bugs and
regressions. We can revisit this properly in Juno.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to work.
Looks right. Thanks!
Can you please open a bug and submit a patch? We should target the fix
to icehouse-rc1.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
. Alternatives are *way*
too risky to be doing in feature freeze, IMO.
I think it's great to see discussion of better ways to approach these
things, but it would have to be Juno work.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
to the contrary.
Happy to be removed. I haven't been active in the last few months.
Best wishes!
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
in the style of Trove. I'm not sure that
actually makes sense (an application template you can deploy may
suffice here). In any case, I view OpenStack's use case and anyone
wanting to use qpid/rabbit/whatever directly separate and out of scope
of Marconi.
--
Russell Bryant
it for the v3 API that is still being worked on. I hope to see that get
movement again during Juno.
--
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
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, it seems quite
likely that we would continue using this exact process, even with
Storyboard. Storyboard isn't a review tool and won't solve all of the
project's problems.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
. We can use
that to help show how to get involved and provide feedback.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
tools that
do testing and merging of changes respect these dependencies. Changes
will only be tested with the other changes they depend on. They will
also only be merged once all changes they depend on have been merged.
--
Russell Bryant
___
OpenStack
some
sort of points for number of commits).
Some related good docs on splitting up changes:
https://wiki.openstack.org/wiki/GitCommitMessages
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
is a blueprint URL.
On the launchpad side, nothing will be allowed to be targeted to a
milestone with an approved spec attached to it.
[1] https://wiki.openstack.org/wiki/ProjectTestingInterface
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
to go into
each release, as well as it's current status.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 03/24/2014 02:19 PM, Monty Taylor wrote:
On 03/24/2014 10:07 AM, Russell Bryant wrote:
On 03/24/2014 12:34 PM, James E. Blair wrote:
Hi,
So recently we started this experiment with the compute and qa programs
to try using Gerrit to review blueprints. Launchpad is deficient in
this area
On 03/25/2014 12:01 AM, Stefano Maffulli wrote:
On 03/24/2014 09:20 AM, Russell Bryant wrote:
Another critical point of clarification ... we are *not* moving out of
blueprints at all. We're still using them for tracking, just as before.
We are *adding* the use of gerrit for reviewing
earlier before we went into the cycle of review/fix/format etc.
I think the key point is the current timing. We're aiming to do RC1 for
projects this week if possible. FFEs were really only allowed weeks ago.
--
Russell Bryant
___
OpenStack-dev mailing
. Otherwise, the problem hasn't
been solved. Some deployments chase trunk and we'd still have this
confusion in the dev community, as well.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
On 03/26/2014 06:30 AM, Thierry Carrez wrote:
Russell Bryant wrote:
[...]
First, it seems there isn't a common use of deprecated. To me,
marking something deprecated means that the deprecated feature:
- has been completely replaced by something else
- end users / deployers should take
with the SDK team, to brainstorm solutions to that problem.
Logging on half of the API calls is obviously bad, but logging a single
time seems reasonable. Deployers need to know it's deprecated, too. If
an API is going away, they have to make plays to test/deploy the new thing.
--
Russell Bryant
/
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
#active
[4] https://wiki.openstack.org/wiki/Nova#Nova_subteams
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
confident that Dan would be a fantastic PTL for Nova.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
closed, the biggest blocker to considering it for
merging would be a CI platform that's running Nova in this setup against
every patch. We require that for all hypervisor drivers now.
https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan
--
Russell Bryant
is adequately documented.
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
of tree.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
)
# Deprecated group/name - [DEFAULT]/libvirt_type
#virt_type=kvm
So, the old option was:
[DEFAULT]
libvirt_type=kvm
The new option is:
[libvirt]
virt_type=kvm
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
On 04/01/2014 11:16 AM, Daniel P. Berrange wrote:
On Mon, Mar 31, 2014 at 01:17:39PM -0400, Russell Bryant wrote:
On 03/31/2014 01:01 PM, Michał Dubiel wrote:
Hi All,
I have prepared commits I would like to have it reviewed and eventually
merged that add initial, limited support for FreeBSD
in the technical sense, but it is a new column in
our support matrix, so I was thinking the same testing requirements
should apply.
https://wiki.openstack.org/wiki/HypervisorSupportMatrix
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
for everyone. Renaming your OpenStack project will become as
simple as a single request to the v4 REST API using XML encoded JSON.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
a status page for
every CI system, like this:
https://wiki.openstack.org/wiki/NovaVMware/Minesweeper/Status
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
it ends
up in a state that Nova is happy with.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to handle sample
config files consistently across projects. If a usability enhancement
related to examples is made, it will then make its way to all projects.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
:
https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
changes to use its service
credentials instead of the user credentials. I don't think any changes
are needed in Nova.
Is there anything missing to support your use case using that approach?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
notifications for
trove managed instances will have the user's info in them. Do you not
want to lose that? If that's the problem, that seems solvable with a
much simpler approach.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 04/06/2014 03:22 PM, Vipul Sabhaya wrote:
On Sun, Apr 6, 2014 at 9:36 AM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
On 04/06/2014 09:02 AM, Christopher Yeoh wrote:
On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin
justin.hop...@hp.com
On 04/07/2014 02:12 PM, Russell Bryant wrote:
On 04/07/2014 01:43 PM, Day, Phil wrote:
Generally the scheduler’s capabilities that are exposed via hints can be
enabled or disabled in a Nova install by choosing the set of filters
that are configured. However the server group feature doesn’t
by screwing up future schedule
requests.
Right. We don't want to punish users for an operational error or mistake.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
the schedule completed at least a week in advance of the summit.
Thanks!
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
.
The process is generally merging the fix to master and then backporting
it. In this case the backport can't be the same. Instead of using a
new migration number, we'll use one of the migration numbers reserved
for havana backports.
--
Russell Bryant
a trivial error in a migration that affects a new feature in
havana. So, at least it's not a regression. It also leaves most of the
feature working fine (setting most user quotas should work just fine).
--
Russell Bryant
___
OpenStack-dev mailing list
?
For the main tree, I think we already do something like this in
practice. Core reviewers look for feedback (+1/-1) from experts of that
code and take it heavily into account when doing the review.
--
Russell Bryant
___
OpenStack-dev mailing list
On 10/11/2013 10:41 AM, Alessandro Pilotti wrote:
On Oct 11, 2013, at 17:17 , Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com
wrote:
On 10/11/2013 09:02 AM, Alessandro Pilotti wrote:
OpenStack is organized differently: there are lots of separate
projects (Nova, Neutrom
On 10/11/2013 12:04 PM, John Griffith wrote:
On Fri, Oct 11, 2013 at 9:12 AM, Bob Ball bob.b...@citrix.com
mailto:bob.b...@citrix.com wrote:
-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com
mailto:rbry...@redhat.com]
Sent: 11 October 2013
Message-
From: Russell Bryant [mailto:rbry...@redhat.com
mailto:rbry...@redhat.com]
Sent: 11 October 2013 15:18
To: openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Hyper-V] Havana status
-October/016470.html
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 10/11/2013 05:09 PM, Alessandro Pilotti wrote:
My suggestion is to bring this discussion to HK, possibly with a few beers
in front and sort it out :-)
Sounds like a good plan to me!
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
that you are comfortable with.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015370.html
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
convention to start using for all changes that
affect upgrades in some way.
Any comments/suggestions/objections? If not, I'll get this documented on:
https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references
--
Russell Bryant
feel that there are downsides too, but it's your call. If you'd like to
go this route, just let me know so we can coordinate, and we can remove
the driver from the nova tree.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
driver be
separate but still an official project.
I think drivers need to be treated equally in this regard, and I think
the majority consensus is that it's best overall to have them in the tree.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack
Nova just discover which versions and pick one (v2) ? And if you
don't like the way Nova picks one, a deployer can just only expose one
of the APIs on the API endpoint that Nova uses.
Thoughts?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack
that the VMWare driver moves from class C to class B on
this page:
https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Compute_Drivers
Thank you, and congratulations on the excellent work to the VMWare team!
--
Russell Bryant
___
OpenStack-dev mailing list
a huge task.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
about what drove you to think you needed to
bypass Nova?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
a session in the Nova track about
docker. I'll be sure to not schedule it on top of the Heat track so
that we can discuss this as a part of the future of docker in OpenStack.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
.
[1] http://summit.openstack.org/cfp/details/341
[2] https://launchpad.net/~nova-drivers/+members#active
[3]
http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
!
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
works. There are a number of things Solum needs to
do on top of Heat, though, such as the git integration bit.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
On 10/24/2013 07:43 AM, Joe Gordon wrote:
On Wed, Oct 23, 2013 at 4:33 PM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
Here is a first cut at the process. Let me know what you think is
missing or should change. I'll get the result of this thread posted
reviewers: russellb, dansmith
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
for *everything*.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
support something like that (from oslo-incubator's logging code):
# list of logger=LEVEL pairs (list value)
#default_log_levels=amqplib=WARN,sqlalchemy=WARN,boto=WARN,suds=INFO,keystone=INFO,eventlet.wsgi.server=WARN
--
Russell Bryant
___
OpenStack
On 10/24/2013 11:32 AM, Thierry Carrez wrote:
Russell Bryant wrote:
At the last Nova meeting we started talking about some updates to the
Nova blueprint process for the Icehouse cycle. I had hoped we could
talk about and finalize this in a Nova design summit session on Nova
Project Structure
It would be helpful if you could follow the reply style being used. :-)
-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com]
Sent: October-24-13 5:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Blueprint review process
On 10/24
doing backports, I would just leave the commit
message alone.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
understand if you can't shuffle things.
I just swapped a bunch of stuff between Tuesday and Wednesday. The
project structure and process session, as well as the scheduler
sessions, are now on Wednesday.
--
Russell Bryant
___
OpenStack-dev mailing list
for intense workloads) or Instance Group Model and API Extension? I
could move them.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to ephemeral disks.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to allow you to include those in your stacks.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 10/29/2013 04:24 PM, Stefano Maffulli wrote:
On 10/28/2013 10:28 AM, Russell Bryant wrote:
2) Setting clearer expectations. Since we have so many blueprints for
Nova, I feel it's very important to accurately set expectations for how
the priority of different projects compare. In the last
On 10/29/2013 07:14 PM, Tom Fifield wrote:
On 30/10/13 07:58, Russell Bryant wrote:
On 10/29/2013 04:24 PM, Stefano Maffulli wrote:
On 10/28/2013 10:28 AM, Russell Bryant wrote:
2) Setting clearer expectations. Since we have so many blueprints for
Nova, I feel it's very important
that Nova managing VMs that it didn't create is not an
appropriate use case to support.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 10/30/2013 02:26 AM, Tom Fifield wrote:
On 30/10/13 17:14, Russell Bryant wrote:
On 10/29/2013 07:14 PM, Tom Fifield wrote:
So, how would you feel about giving some priority manipulation abilities
to the user committee? :)
Abilities, no, but input, of course.
Any practical ideas
Greetings,
The next two Nova meetings are canceled. We will resume our weekly
meetings on Thursday, Nov 7. Get those Icehouse blueprints filed and in
shape in the meantime!
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
On 10/30/2013 10:59 AM, Russell Bryant wrote:
Greetings,
The next two Nova meetings are canceled. We will resume our weekly
meetings on Thursday, Nov 7. Get those Icehouse blueprints filed and in
shape in the meantime!
Thanks,
Oops, we will resume on the *14* of November, not the 7th
the place to talk about it. It's
getting a lot better.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
having one way to deploy nova (cells). Having both cells
vs non-cells options really isn't ideal long term.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
) have had to inherit it. For new projects, you should use
alembic. That's actively developed and maintained. Other OpenStack
projects are either already using it, or making plans to move to it.
--
Russell Bryant
___
OpenStack-dev mailing list
On 11/01/2013 05:50 PM, Michael Still wrote:
On Sat, Nov 2, 2013 at 3:30 AM, Russell Bryant rbry...@redhat.com wrote:
I also would not use migrate. sqlalchemy-migrate is a dead upstream and
we (OpenStack) have had to inherit it. For new projects, you should use
alembic. That's actively
already using it, or making plans to move to it.
Thanks, did not see it in the projects I was looking at, who's the
canonical example here?
It looks like at leat ceilometer and neutron are using alembic right now.
--
Russell Bryant
___
OpenStack
/4a7316a4f5c6f783e362cbba2644bae2
[3] https://review.openstack.org/#/c/55040/
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 10/30/2013 11:35 PM, Daniel P. Berrange wrote:
On Wed, Oct 30, 2013 at 04:20:34AM -0400, Russell Bryant wrote:
On 10/30/2013 03:13 AM, Alex Glikson wrote:
Maybe a more appropriate approach could be to have a tool/script that
does it, as a one time thing.
For example, it could make sense
to make sure that nova's and hypervisor's view of the world
are in sync. If not, it will takes a series of actions to correct the
situation.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
for enterprise virtualization.
In an elastic cloud workload world, this use case just doesn't make sense.
If it's about disaster recovery, that's a bit different, but as Daniel
Berrange pointed out in this thread, this is just part of that picture,
and probably not the place to start.
--
Russell
.
[1]
http://git.openstack.org/cgit/openstack/oslo-incubator/tree/openstack/common/log.py
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
filters to let them
indicate where in the order of filters they should run?
The filters you're talking about here we would probably want to run
last. Other filters that could potentially efficiently eliminate a
large number of hosts should be run first.
--
Russell Bryant
On 11/03/2013 03:12 PM, Russell Bryant wrote:
On 11/01/2013 06:39 AM, Jiang, Yunhong wrote:
I noticed several filters (AggregateMultiTenancyIsoaltion, ram_filter,
type_filter, AggregateInstanceExtraSpecsFilter) have DB access in the
host_passes(). Some will even access for each invocation
logo -
but the placeholder right now isn't too bad either, is it?
One nit, instead of linking to github, it would be better to link to
OpenStack's git interface since that's what we're trying to provide as
the canonical repo now.
http://git.openstack.org/cgit/stackforge/solum
--
Russell Bryant
an email address with '+' in it for
some other reason, right?
I think it may be worth looking at this from a different angle. Perhaps
we should tone down the focus on company metrics, and perhaps remove
them completely from anything we control or have influence over.
--
Russell Bryant
On 11/11/2013 12:08 PM, Mark McLoughlin wrote:
On Mon, 2013-11-11 at 11:41 -0500, Russell Bryant wrote:
On 11/11/2013 10:57 AM, Mark McLoughlin wrote:
Hi Nick,
On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
Dear TC members,
Our companies are actively encouraging our respective
to relax.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Winter in Canada... I'd be quite surprised if someone went without
shoes.
I love the idea, but this stuff is just a big turn-off.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
/DeprecationPlan
[2] https://blueprints.launchpad.net/nova/+spec/gce-api
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
://lists.openstack.org/pipermail/openstack-dev/2013-October/017290.html
[2] https://etherpad.openstack.org/p/NovaIcehouseProjectStructureAndProcess
[3] https://wiki.openstack.org/wiki/Blueprints
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack
201 - 300 of 779 matches
Mail list logo
