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 than
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 migratio
Thanks Igor for the quick turn over, excellent!
On Fri, Jan 30, 2015 at 1:19 AM, Igor Belikov 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 also been changed,
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.
an
On Fri, Jan 30, 2015 at 3:05 AM, Kenichi Oomichi
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: [openstack-dev] [api][
On Thu Jan 29 2015 at 12:59:34 AM Mike Bayer 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 perfectly fine and
>
+1
Very excited to see this in and usable
Duncan Thomas
On Jan 30, 2015 2:56 AM, "Philipp Marek" 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 using iSCSI for
2015-01-29 19:31 GMT+01:00 Joe Gordon :
> 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
issue with upgrades whe
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
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 workarou
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 A
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
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, specificall
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 :
> Hi All!
> Thanks for the feedback!
>
> I'll remove xattr from the requirements in my change set.
Hi,
Thanks for this updates. Thats super useful.
On 28 January 2015 at 13:21, Gary Kotton 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 need to update the
>
>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, 2
On 29 January 2015 at 04:57, Chris Friesen
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 our
>> side.
>
>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 the
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 co
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-req
On Thu, Jan 29, 2015 at 5:01 PM, Jay Faulkner wrote:
>
> On Jan 29, 2015, at 2:52 PM, Kevin Benton 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 in their current ad-ho
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:
>
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
On Fri, Jan 30, 2015 at 4:20 AM, 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
> o
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 th
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 n
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
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:
https://g
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 migratio
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:
https://review.
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
El
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 runn
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). Rea
Thanks for the answer. Can I help with implementation of novaclient part?
On Wed, Jan 28, 2015 at 11:50 AM, Christopher Yeoh
wrote:
> On Fri, 23 Jan 2015 15:51:54 +0200
> Andrey Kurilin wrote:
>
> > Hi everyone!
> > After removing nova V3 API from novaclient[1], implementation of v1.1
> > clien
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
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
coup
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 undercl
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 wrote:
> Magnum Cores,
>
> I propose the following addition to the Magnum Core group[1]:
>
> + Hongbin Lu (hongbin034)
>
> Please let me know you
Andrew Pashkin 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 for generation
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:
> http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/kilo/make-enginefacade-a-facade
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
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} Twitter/Ident
+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
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 in acceptable state f
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, t
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 EC
On Jan 29, 2015, at 11:41 AM, Sean Dague 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 goes wron
On Jan 29, 2015, at 7:34 PM, Rochelle Grober
mailto: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 logging that kept circ
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 the
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 l
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 b
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 tripleo-heat
On Jan 30, 2015, at 3:17 PM, Jesse Keating 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 bad and it c
On Fri, Jan 30, 2015 at 3:08 PM, Everett Toews
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 with. Including this in an
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
wrote:
LDAP is used in Keystone as a backend for both the Identity (Users and groups)
and assignments (assigning roles to users) backend.
Where did the LDAP As
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 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
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 dur
On 1/29/2015 7:42 PM, Michael Still wrote:
On Thu, Jan 29, 2015 at 5:15 PM, Michael Still 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 we go:
https://bug
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 api-wg
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 were
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 Nova
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...
On Fri, Jan 30, 2015 at 4:03 PM, Everett Toews
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 than the ones created by movi
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 p
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 w
On Jan 30, 2015, at 4:57 PM, Everett Toews 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 highlighted the need for
On Fri, Jan 30, 2015 at 4:57 PM, Everett Toews
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 converge.
Tweetable, 126 char
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 wrote:
> As you know we have been driving forward on the s
On Fri, Jan 30, 2015 at 5:21 PM, Davanum Srinivas 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 an external plu
On Fri, Jan 30, 2015 at 2:17 AM, Alan Pevec wrote:
> 2015-01-29 19:31 GMT+01:00 Joe Gordon :
> > 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 client
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 m
On Friday, January 30, 2015, Jeremy Stanley 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
--
--
Dean T
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 Lis
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:
http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/kilo/make-enginefaca
On 31 January 2015 at 10:25, Gregory Haynes 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,
>> > and i
> - 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
http://git.openstack.org/cgit/openst
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).
--Morga
- Original Message -
> From: "Daniel P. Berrange"
> 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 recent Nova mi
On 01/28/2015 06:33 PM, Johannes Erdfelt wrote:
> On Wed, Jan 28, 2015, Mike Bayer 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 else.
>> H
80 matches
Mail list logo