Kevin,
The only thing this discussion has convinced me of is that allowing users to
change the fixed IP address on a neutron port leads to a bad user-experience.
Even with an 8-minute renew time you're talking up to a 7-minute blackout (87.5%
of lease time before using broadcast). This is time
On Thu, Jan 29, 2015, at 07:03 PM, Angus Lees wrote:
The other factor I haven't seen mentioned here is that our usual
eventlet+mysqldb setup can deadlock rather easily(*), resulting in the
entire python process sitting idle for 30s until the mysqldb deadlock
timer
goes off and raises an
At some point in the near future, hopefully early in L, we're intending
to update Nova to use the new database transaction management in
oslo.db's enginefacade.
Spec:
http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/kilo/make-enginefacade-a-facade.rst
Implementation:
I was asking earlier this week about keystone resources on the irc channel...
We're thinking about having a tenant per user on one of our clouds. We're using
neutron. So setting this up involves:
* Creating a User
* Creating a Tenant
* Assigning Roles
* Creating the Tenants default Private
Cool,
I've got to try that out today to see what it's doing.
I've also shoved my little program up @
https://github.com/harlowja/pippin (the pip-tools one is definitely more
elegantly coded than mine, haha).
Feel free to fork it (modify, run, or ...)
Basic instructions to use it:
In working on a recent Nova migration bug
https://bugs.launchpad.net/nova/+bug/1414065
I had cause to refactor the way the nova libvirt driver monitors live
migration completion/failure/progress. This refactor has opened the
door for doing more intelligent active management of the live
On Thu, Jan 29, 2015 at 5:01 PM, Jay Faulkner j...@jvf.cc wrote:
On Jan 29, 2015, at 2:52 PM, Kevin Benton blak...@gmail.com wrote:
Oh, I understood it a little differently. I took parsing of error
messages here is not the way we’d like to solve this problem as meaning
that parsing them
Hi,
The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in Gerrit) and root members (people with
administrative access). Read all about it here:
http://ci.openstack.org/project.html#team
On Thu, Jan 29, 2015, at 09:10 PM, liuxinguo wrote:
* I have seen that the module 'oslo.config' have changed to
'oslo_config' in Kilo but in Juno it is still 'oslo.config'.
I want my code work compatibly both for Juno and Kilo so I import this
module in this way:
try:
from
On Fri, 30 Jan 2015, Doug Hellmann wrote:
My impression of this thread is that we're reaching consensus that we
should move to PyMySQL, but that we want to make that move carefully
because we expect issues due to the changes in performance and context
switching behaviors. We've seen in the past
On Fri, Jan 30, 2015, at 09:20 AM, James E. Blair wrote:
Hi,
The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in Gerrit) and root members (people with
administrative access). Read all
On Fri, Jan 30, 2015 at 4:20 AM, Steven Hardy sha...@redhat.com wrote:
On Thu, Jan 29, 2015 at 12:31:17PM -0500, Zane Bitter wrote:
On 29/01/15 12:03, Steven Hardy wrote:
On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote:
IIUC keystone now allows you to add users to a domain that
On 2015-01-30 09:20:44 -0800 (-0800), James E. Blair wrote:
[...]
Elizabeth K. Joseph has been reviewing a significant number of infra
patches for some time now. She has taken on a number of very large
projects, including setting up our Git server farm, adding support for
infra servers running
On Jan 29, 2015, at 7:34 PM, Rochelle Grober
rochelle.gro...@huawei.commailto:rochelle.gro...@huawei.com wrote:
Hi folks!
Changed the tags a bit because this is a discussion for all projects and
dovetails with logging rationalization/standards/
At the Paris summit, we had a number of session
On January 29, 2015 at 3:19:34 AM, Yuriy Taraday (yorik@gmail.com) wrote:
Hello.
On Wed Jan 28 2015 at 11:30:43 PM Morgan Fainberg morgan.fainb...@gmail.com
wrote:
LDAP is used in Keystone as a backend for both the Identity (Users and groups)
and assignments (assigning roles to users)
On 1/30/2015 3:16 PM, Soren Hansen wrote:
As I've said a couple of times in the past, I think the
architecturally sound approach is to keep this inside Nova.
The two main reasons are:
* Having multiple frontend API's keeps us honest in terms of
separation between the different layers in
Hi All,
Something we in the API WG keep bumping into are misconceptions around what our
mission really is. There’s general agreement in the WG about our mission but we
haven’t formalized it.
It’s really highlighted the need for a mission statement/elevator pitch/mantra
that we can repeat to
On Jan 30, 2015, at 4:57 PM, Everett Toews everett.to...@rackspace.com wrote:
Hi All,
Something we in the API WG keep bumping into are misconceptions around what
our mission really is. There’s general agreement in the WG about our mission
but we haven’t formalized it.
It’s really
On Fri, Jan 30, 2015 at 4:57 PM, Everett Toews everett.to...@rackspace.com
wrote:
What is the API WG mission statement?
It's more of a mantra than a Mission Statement(TM):
Identify existing and future best practices in OpenStack REST APIs to
enable new and existing projects to evolve and
Alexandre, Randy,
Are there plans afoot to add support to switch on stackforge/ec2-api
in devstack? add tempest tests etc? CI Would go a long way in
alleviating concerns i think.
thanks,
dims
On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy randy.b...@emc.com wrote:
As you know we have been
On Jan 29, 2015, at 11:41 AM, Sean Dague s...@dague.net wrote:
Correct. This actually came up at the Nova mid cycle in a side
conversation with Ironic and Neutron folks.
HTTP error codes are not sufficiently granular to describe what happens
when a REST service goes wrong, especially if it
Excerpts from Gregory Haynes's message of 2015-01-30 18:28:19 +:
Excerpts from Steven Hardy's message of 2015-01-30 10:29:05 +:
Hi all,
I've had a couple of discussions lately causing me to question $subject,
and in particular what our expectations are around
The suggestion of whether to use 1 or 2 repos for the API WG surfaced on the ML
here [1]. That thread then morphed into a discussion on whether to use 1 or 2
repos. I believe it’s correct to say that the consensus on that thread was for
1 repo.
We also discussed the question of 1 or 2 repos
On 1/29/2015 7:42 PM, Michael Still wrote:
On Thu, Jan 29, 2015 at 5:15 PM, Michael Still mi...@stillhq.com wrote:
There is an ec2 bug tag in launchpad. I would link to it except I am writing
this offline. I will fix that later today.
Ok, now that the 40 seater turbo prop has landed, here
Hi-
I believe I'm the one who was volunteered for this on IRC. I'm still fine
with being the contact for these matters, but making the meetings at
0800/1500 UTC will be difficult for me. Feel free to sign me up if that
is not a blocker. I've been driving the ironic CI/QA stuff over the last
On 01/30/2015 06:20 PM, James E. Blair wrote:
[...]
Please respond with any comments or concerns.
Thanks, Elizabeth, for all your work!
It's a pleasure seeing her thorough reviews and I agree she'll be a
great addition,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org}
On Jan 30, 2015, at 3:17 PM, Jesse Keating j...@bluebox.net wrote:
On 1/30/15 1:08 PM, Everett Toews wrote:
Project: A client dealing with the API already knows what project
(service) they’re dealing with. Including this in an API error message
would be redundant. That’s not necessarily so
A Huge +1 from me.
—Morgan
--
Morgan Fainberg
On January 30, 2015 at 9:20:06 AM, James E. Blair (cor...@inaugust.com) wrote:
Hi,
The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in
On Fri, Jan 30, 2015 at 4:03 PM, Everett Toews everett.to...@rackspace.com
wrote:
Now the question becomes, which repo?
I think the current one serves the community best. AIUI the reason for
thinking about a change was for visibility. As before, I think that is an
easier problem to solve
As I've said a couple of times in the past, I think the
architecturally sound approach is to keep this inside Nova.
The two main reasons are:
* Having multiple frontend API's keeps us honest in terms of
separation between the different layers in Nova.
* Having the EC2 API inside Nova ensures
As you know we have been driving forward on the stack forge project and
it¹s our intention to continue to support it over time, plus reinvigorate
the GCE APIs when that makes sense. So we¹re supportive of deprecating
from Nova to focus on EC2 API in Nova. I also think it¹s good for these
APIs to
On Fri, 2015-01-30 at 21:08 +, Everett Toews wrote:
Project: A client dealing with the API already knows what project
(service) they’re dealing with. Including this in an API error message
would be redundant. That’s not necessarily so bad and it could
actually be convenient for client
On 01/30/2015 12:08 PM, Adam Gandelman wrote:
Hi-
I believe I'm the one who was volunteered for this on IRC.
Ah yes, it was you. Thank you Adam and sorry I had mind blanked on your
name.
I'm still fine
with being the contact for these matters, but making the meetings at
0800/1500 UTC will
It was suggested that the API WG use the openstack-specs [1] and/or the api-wg
[2] repo to publish its guidelines. We’ve already arrived at the consensus that
we should only use 1 repo [3]. So the purpose of this thread is to decide...
Should the API WG use the openstack-specs repo or the
On Fri, 2015-01-30 at 22:33 +, Everett Toews wrote:
It was suggested that the API WG use the openstack-specs [1] and/or
the api-wg [2] repo to publish its guidelines. We’ve already arrived
at the consensus that we should only use 1 repo [3]. So the purpose of
this thread is to decide...
We have a new Sphinx theme for docs.openstack.org, called
openstackdocstheme. It should be available on pipy as soon as we can get it
released. Once that's released I'll write instructions for how to apply it
to migrated content. A huge thanks to Doug Hellman for getting it to
releasable!
We are
On Fri, Jan 30, 2015 at 3:08 PM, Everett Toews everett.to...@rackspace.com
wrote:
I like the idea of the log error codes being aligned with the API errors
codes but I have some thoughts/concerns.
Project: A client dealing with the API already knows what project
(service) they’re dealing
On 1/29/2015 5:52 AM, Alexandre Levine wrote:
Thomas,
I'm the lead of the team working on it.
The project is in a release-candidate state and the EC2 (non-VPC) part
is just being finished, so there are no tags or branches yet. Also we
were not sure about what should we do with it since we
Thanks for the answer. Can I help with implementation of novaclient part?
On Wed, Jan 28, 2015 at 11:50 AM, Christopher Yeoh cbky...@gmail.com
wrote:
On Fri, 23 Jan 2015 15:51:54 +0200
Andrey Kurilin akuri...@mirantis.com wrote:
Hi everyone!
After removing nova V3 API from novaclient[1],
Excerpts from Steven Hardy's message of 2015-01-30 10:29:05 +:
Hi all,
I've had a couple of discussions lately causing me to question $subject,
and in particular what our expectations are around tripleo-heat-templates
working with older (e.g non trunk) versions of Heat in the undercloud.
Andrew Pashkin apash...@mirantis.com wrote:
Working on this issue I encountered another problem.
Most indices in the project has no names and because of that,
developer must reverse-engineer them in every migration.
Read about that also here [1].
SQLAlchemy and Alembic provide feature
Matthew Booth mbo...@redhat.com wrote:
At some point in the near future, hopefully early in L, we're intending
to update Nova to use the new database transaction management in
oslo.db's enginefacade.
Spec:
Magnum Cores,
Thanks for your votes. Hongbin has been added to the core group. Welcome!
Regards,
Adrian
On Jan 28, 2015, at 2:27 PM, Adrian Otto adrian.o...@rackspace.com wrote:
Magnum Cores,
I propose the following addition to the Magnum Core group[1]:
+ Hongbin Lu (hongbin034)
Hi,
As part of an effort to better support re-use of the Infrastructure
program's software, tooling, and systems-administration work, we have
moved all of our puppet modules out of the system-config repository.
Now each of them may be found in its own git repo, such as
openstack-infra/puppet-zuul
Michael,
Our team can take the effort. We're the ones doing the stackforge EC2
API and we can maintain the nova's EC2 in acceptable state for the time
being as well.
If you can give us any permissions and leverage to not just contribute
fixes and tests but also have a say in approval of those
Tim,
We sure we can fix it and we know how. The only problem is to somehow
get a hand with reviewing and approvals speed? Is there any remedy for
this? I've asked Michael already above in the thread, but I don't
presume that it's possible even to allow one of us to become core
reviewer for
Alex,
Many thanks for the constructive approach. I've added an item to the list for
the Ops meetup in March to see who would be interested to help.
As discussed on the change, it is likely that there would need to be some
additional Nova APIs added to support the full EC2 semantics. Thus,
+1 cloudscaling has been pretty involved in ec2 support for openstack for a
long while now.
On Fri, Jan 30, 2015 at 2:27 PM, Alexandre Levine alev...@cloudscaling.com
wrote:
Michael,
Our team can take the effort. We're the ones doing the stackforge EC2 API
and we can maintain the nova's EC2
As point, we are trying to move away from this model. Having to know the
dependencies is a bad experience in general. But with the move to eliminate
optional parts of the api, most of these become real dependencies for
keystone (a few things will still be optional eg memcache lib).
--Morgan
- Original Message -
From: Daniel P. Berrange berra...@redhat.com
To: openstack-dev@lists.openstack.org, openstack-operat...@lists.openstack.org
Sent: Friday, 30 January, 2015 11:47:16 AM
Subject: [openstack-dev] [nova][libvirt] RFC: ensuring live migration ends
In working on a
On 31 January 2015 at 10:25, Gregory Haynes g...@greghaynes.net wrote:
Excerpts from Gregory Haynes's message of 2015-01-30 18:28:19 +:
Excerpts from Steven Hardy's message of 2015-01-30 10:29:05 +:
Hi all,
I've had a couple of discussions lately causing me to question $subject,
On Fri, Jan 30, 2015 at 2:17 AM, Alan Pevec ape...@gmail.com wrote:
2015-01-29 19:31 GMT+01:00 Joe Gordon joe.gord...@gmail.com:
That means clients need overlapping dependencies with the stable
branches.
I don't think this is a reasonable requirement, and am not sure what we
gain from it.
On 2015-01-30 17:18:00 -0600 (-0600), Dean Troyer wrote:
[...]
Identify existing and future best practices in OpenStack REST APIs
to enable new and existing projects to evolve and converge.
[...]
I'm shuddering at the anti-term best practices there. How about
ideals instead? More shorter means
On Friday, January 30, 2015, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-01-30 17:18:00 -0600 (-0600),
I'm shuddering at the anti-term best practices there. How about
ideals instead? More shorter means more twittable too, right?
I'd buy that even if it costs a buzzword point.
dt
--
On 2015-01-30 18:25:43 -0600 (-0600), Dean Troyer wrote:
I'd buy that even if it costs a buzzword point.
The Vancouver summit needs buzzword bingo as a social event.
--
Jeremy Stanley
__
OpenStack Development Mailing List
On 01/28/2015 06:33 PM, Johannes Erdfelt wrote:
On Wed, Jan 28, 2015, Mike Bayer mba...@redhat.com wrote:
I can envision turning this driver into a total monster, adding
C-speedups where needed but without getting in the way of async
patching, adding new APIs for explicit async, and everything
On Fri, Jan 30, 2015 at 5:21 PM, Davanum Srinivas dava...@gmail.com wrote:
Are there plans afoot to add support to switch on stackforge/ec2-api
in devstack? add tempest tests etc? CI Would go a long way in
alleviating concerns i think.
I would encourage DevStack support to be implemented as
On 1/30/2015 11:05 AM, Matthew Booth wrote:
At some point in the near future, hopefully early in L, we're intending
to update Nova to use the new database transaction management in
oslo.db's enginefacade.
Spec:
- Remove this requirement, no optional entries in requirements.txt, a
'deployer' has to know what dependencies the components he wants to use have
Keystone is documenting its optional dependencies in test-requirements.txt
look for # Optional ... comments in
On Thu Jan 29 2015 at 12:59:34 AM Mike Bayer mba...@redhat.com wrote:
Hey list -
Hey, Mike.
While PyMySQL is lacking test coverage in some areas, has no external
documentation, and has at least some areas where Python performance can be
improved, the basic structure of the driver is
+1
Very excited to see this in and usable
Duncan Thomas
On Jan 30, 2015 2:56 AM, Philipp Marek philipp.ma...@linbit.com wrote:
Hi all,
in Paris (and later on, on IRC and the mailing list) I began to ask
around
about providing a DRBD storage driver for Nova.
This is an alternative to
On Thu, Jan 29, 2015 at 12:31:17PM -0500, Zane Bitter wrote:
On 29/01/15 12:03, Steven Hardy wrote:
On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote:
IIUC keystone now allows you to add users to a domain that is otherwise
backed by a read-only backend (i.e. LDAP). If this means that
2015-01-29 19:31 GMT+01:00 Joe Gordon joe.gord...@gmail.com:
That means clients need overlapping dependencies with the stable branches.
I don't think this is a reasonable requirement, and am not sure what we gain
from it.
Capping all Oslo and clients on stable/juno was reverted[1] due to
On Fri, Jan 30, 2015 at 3:05 AM, Kenichi Oomichi oomi...@mxs.nes.nec.co.jp
wrote:
-Original Message-
From: Roman Podoliaka [mailto:rpodoly...@mirantis.com]
Sent: Friday, January 30, 2015 2:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re:
Hi all,
I've had a couple of discussions lately causing me to question $subject,
and in particular what our expectations are around tripleo-heat-templates
working with older (e.g non trunk) versions of Heat in the undercloud.
For example, in [1], we're discussing merging a template-level
What do you guys think about switching CentOS CI job [1] to HA with single
controller (1 controller + 1 or 2 computes)? Just to verify that our
replacement of Simple mode works fine.
[1]
https://fuel-jenkins.mirantis.com/job/master.fuel-library.centos.ha_nova_vlan/
On Fri, Jan 30, 2015 at 10:54
Hello everyone!
A change has been merged yesterday [1] that propose default security group
table to Neutron. It passed all checks well. But now from time to time I
see that check-grenade-dsvm-neutron fails on db upgrade as it has more than
one default security group in one tenant. Having more
On Friday 30 January 2015 01:01:00 Boris Bobrov wrote:
On Thursday 29 January 2015 22:06:25 Morgan Fainberg wrote:
I’d like to propose we stop setting the expectation that a downwards
migration is a “good idea” or even something we should really support.
Offering upwards-only migrations
Hi all,
in Paris (and later on, on IRC and the mailing list) I began to ask around
about providing a DRBD storage driver for Nova.
This is an alternative to using iSCSI for block storage access, and would
be especially helpful for backends already using DRBD for replicated
storage.
any
Thanks Igor for the quick turn over, excellent!
On Fri, Jan 30, 2015 at 1:19 AM, Igor Belikov ibeli...@mirantis.com wrote:
Folks,
Changes in CI jobs have been made, for master branch of fuel-library we
are running CentOS HA + Nova VLAN and Ubuntu HA + Neutron VLAN .
Job naming schema has
Hello again,
i submitted a new patch set for this at
https://review.openstack.org/#/c/110722/ ,
looking forward to further reviews. :)
Best regards
Silvan
2015-01-28 10:19 GMT+01:00 Silvan Kaiser sil...@quobyte.com:
Hi All!
Thanks for the feedback!
I'll remove xattr from the requirements in
Hi,
Thanks for this updates. Thats super useful.
On 28 January 2015 at 13:21, Gary Kotton gkot...@vmware.com wrote:
Ephemeral disk support -
https://blueprints.launchpad.net/nova/+spec/vmware-ephemeral-disk-support
I have made that medium, to raise it above the others.
The following BP’s
You may find the code for pip-compile
https://github.com/nvie/pip-tools/tree/future of interest for this, as I
think they may already have a solution for the deep dependency analysis.
I've started experimenting with it for git-upstream cause GitPython have
a habbit of breaking stuff through a
On 30/01/15 05:20, Steven Hardy wrote:
On Thu, Jan 29, 2015 at 12:31:17PM -0500, Zane Bitter wrote:
On 29/01/15 12:03, Steven Hardy wrote:
On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote:
IIUC keystone now allows you to add users to a domain that is otherwise
backed by a read-only
On 01/29/2015 05:24 PM, Doug Hellmann wrote:
On Thu, Jan 29, 2015, at 11:03 AM, Thomas Goirand wrote:
On 01/24/2015 02:01 AM, Doug Hellmann wrote:
On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:
Hi,
I've just noticed that oslo.log made it to global-requirements.txt 9
days
Working on this issue I encountered another problem.
Most indices in the project has no names and because of that,
developer must reverse-engineer them in every migration.
Read about that also here [1].
SQLAlchemy and Alembic provide feature for generation constraint
names by pattern,
From: Johannes Erdfelt [johan...@erdfelt.com]
Sent: Thursday, January 29, 2015 9:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues
On Thu, Jan 29, 2015,
On 29 January 2015 at 04:57, Chris Friesen chris.frie...@windriver.com
wrote:
On 01/28/2015 10:33 PM, Mathieu Gagné wrote:
On 2015-01-28 11:13 PM, Chris Friesen wrote:
Anyone have any suggestions on where to start digging?
We have a similar issue which has yet to be properly diagnosed on
On Thu, 2015-01-29 at 16:01 -0800, Michael Still wrote:
However, we got here because no one is maintaining the code in Nova
for the EC2 API. This is despite repeated calls over the last 18
months (at least).
I'd love to get to the root cause before we jump to look for solutions.
The story we
But they will if we document it well, which is what Salvatore suggested.
I don't think this is a good approach, and it's a big part of why I started
this thread. Most of the deployers/operators I have worked with only read
the bare minimum documentation to get a Neutron deployment working and
80 matches
Mail list logo
