Re: [openstack-dev] [Cinder] Need +A (workflow +1) for https://review.openstack.org/156940

On 03/03/2015 02:17 AM, Deepak Shetty wrote: > Hi all, > Can someone give +A to https://review.openstack.org/156940 - we have > the rest. Need to get this merged for glusterfs CI to pass the > snapshot_when_volume_in_use testcases. > > thanx, > deepak > > > > __

[openstack-dev] [nova] Intended behavior for instance.host on reschedule?

Hi Folks, I was wondering if anyone can comment on the intended behavior of how instance.host is supported to be set during reschedule operations. For example, take this scenario: 1. Assume an environment with a single host… call it host-1 2. Deploy a VM, but force an exception in the spawn pa

Re: [openstack-dev] [Cinder] Need +A (workflow +1) for https://review.openstack.org/156940

Anteaya, In general i agree, but because of TZ differences, not always you can do that. Also i sent mail only for the case where we had all +1, +2, just needed workflow +1, which I think is justfiable ! thanx, deepak On Tue, Mar 3, 2015 at 1:30 PM, Anita Kuno wrote: > On 03/03/2015 02:17 AM,

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

https://review.openstack.org/#/c/159840/1/doc/source/testing/openflow-firewall.rst I may need some help from the OVS experts to answer the questions from henry.hly. Ben, Thomas, could you please? (let me know if you are not registered to the openstack review system, I could answer in your na

[openstack-dev] [nova] Question about boot-from-volume instance and flavor

Hi all, When we boot instance from volume, we find some ambiguous description about flavor root_gb in operations guide, http://docs.openstack.org/openstack-ops/content/flavors.html *Virtual root disk size in gigabytes. This is an ephemeral disk the base image is copied into. You don't use it when

Re: [openstack-dev] [tempest] API testing coverage in tempest

Hi A long time ago, I was asked to do the same job. I tried to come up with a "programmed" way of doing this. For some openstack component, there's a python object called "router" which holds the routes (the URLs that form the API). For nova : https://github.com/openstack/nova/blob/master/nova/ap

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

Doug Wiegley wrote: > [...] > But I think some of the push back in this thread is challenging this notion > that abandoning is negative, which you seem to be treating as a given. > > I don't. At all. And I don't think I'm alone. I was initially on your side: the "abandoned" patches are not real

Re: [openstack-dev] [oslo.policy] guraduation status

Jordan, Thank you for providing the info. On Monday, March 02, 2015 7:41 PM, Jordan Pittier wrote; > The project is abandoned but the initial goal was to have the code > somehow proposed to be merged in Openstack Swift. Feel free to have > a look a continue this effort. I have been developing

[openstack-dev] Cross-Project meeting, Tue March 3rd, 21:00 UTC

Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting today at 21:00 UTC, with the following agenda: * OpenStack developer doc vs. cross-project Specs [1] [2] * Replacing eventlet: metaspec or separate specs [3] [4] * openstack-specs discussion * Add

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

James Bottomley wrote: > Actually, this is possible: look at Linux, it freezes for 10 weeks of a > 12 month release cycle (or 6 weeks of an 8 week one). More on this > below. I'd be careful with comparisons with the Linux kernel. First it's a single bit of software, not a collection of interconne

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On Tue, 3 Mar 2015, Thierry Carrez wrote: I'd be careful with comparisons with the Linux kernel. First it's a single bit of software, not a collection of interconnected projects. Second it's at a very different evolution/maturity point (20 years old vs. 0-4 years old for OpenStack projects). Fin

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

On Tue, 3 Mar 2015, Steve Baker wrote: This looks very useful, I'd like to use this in the heat functional tests job. Awesome, let me know if you need any assistance getting started. Is it possible to write tests which do a POST/PUT then a loop of GETs until some condition is met (a response

Re: [openstack-dev] [Heat][Mistral] How to use Mistral resources in Heat

Hi Peter, Thanks for sharing this.. Overall it looks good to me, I just left a couple of comments/questions in https://review.openstack.org/#/c/147645/17/contrib/heat_mistral/heat_mistral/tests/test_workflow.py

[openstack-dev] Call for mentors - Outreachy (former OPW)

Hi all, Next round application deadline for Outreachy is close and and we need mentors willing to help newcomers to get involved with OpenStack and help them start contributing [0][1]. This would be the 5th time OpenStack joins Outreachy and for now we can say we are having a great outcome for th

[openstack-dev] [neutron][vpnaas] VPNaaS Subteam meetings

Hi all! The email, that I sent on 2/24 didn't make it to the mailing list (no wonder I didn't get responses!). I think I had an issue with my email address used - sorry for the confusion! So, I'll hold the meeting today (1500 UTC meeting-4, if it is still available), and we can discuss this... W

Re: [openstack-dev] [Heat][Mistral] How to use Mistral resources in Heat

Hi Renat, We solved problem with referencing. I'll add more tests for understanding, how Mistral Workflow resource look like in Heat template. 2015-03-03 14:35 GMT+03:00 Renat Akhmerov : > Hi Peter, > > Thanks for sharing this.. Overall it looks good to me, I just left a > couple of comments/qu

Re: [openstack-dev] Python 3 is dead, long live Python 3

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/2015 05:15 PM, Jeremy Stanley wrote: > After a long wait and much testing, we've merged a change[1] which > moves the remainder of Python 3.3 based jobs to Python 3.4. This > is primarily in service of getting rid of the custom workers we >

Re: [openstack-dev] [Heat][Mistral] How to use Mistral resources in Heat

Oooh, ok! Yeah, additional tests for that would help us clearly see that solved. Thanks! Renat Akhmerov @ Mirantis Inc. > On 03 Mar 2015, at 18:03, Peter Razumovsky wrote: > > Hi Renat, > > We solved problem with referencing. I'll add more tests for understanding, > how Mistral Workflow re

[openstack-dev] [mistral] Break_on in Retry policy

Hello, Recently we've found that break_on property of RetryPolicy is not working now. I tried to solve this problem but faced the another problem: How does 'break_on' supposed to work? Will 'break_on' change the task state to ERROR or SUCCESS? if ERROR, it means 'we interrupt all retry iteration

[openstack-dev] [Nova] Should Nova delete the implicit volume and volume snapshot it creates?

Hi, I have a question regarding the implicit volume resources that created by Nova during persistent VM's snapshot creation. Here is a sample scenario that leaves a set of volume resources as residue, 1. Create a bootable volume, bv_1 2. Create an instance vm_1, from the bootable volume bv_1

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

> -Original Message- > From: Thierry Carrez [mailto:thie...@openstack.org] > Sent: 03 March 2015 10:00 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] auto-abandon changesets considered harmful > (was Re: [stable][all] Revisiting the 6 month release cycle [metrics]) >

Re: [openstack-dev] [nova] what's the merge plan for current proposed microversions?

Bump. I'd really appreciate some answers to the question Sean asked. I still have the 2.4 in my review (the very one Sean mentioned) but it seems that it might not be the case. Best regards, Alex Levine On 3/2/15 2:30 PM, Sean Dague wrote: This change for the additional attributes for ec2

Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?

I’m pretty sure it has always done this: leave the host set on the final scheduling attempt. I agree that this could be cleared which would free up room for future scheduling attempts. Vish On Mar 3, 2015, at 12:15 AM, Joe Cropper wrote: > Hi Folks, > > I was wondering if anyone can comment

Re: [openstack-dev] Python 3 is dead, long live Python 3

On Tue, Mar 3, 2015, at 07:56 AM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/02/2015 05:15 PM, Jeremy Stanley wrote: > > After a long wait and much testing, we've merged a change[1] which > > moves the remainder of Python 3.3 based jobs to Python 3.4. Thi

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

On Tue, Mar 3, 2015 at 7:18 AM, Kuvaja, Erno wrote: > > -Original Message- > > From: Thierry Carrez [mailto:thie...@openstack.org] > > Sent: 03 March 2015 10:00 > > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] auto-abandon changesets considered harmful > > (was R

[openstack-dev] [heat][neutron] allowed_address_pairs does not work

Hi, I see that the neutron port resource has a property named as allowed_address_pairs and I tried to use this property to create a port, but seems it does not working. I want to create a port with mac as fa:16:3e:05:d5:9f and ip as 192.168.0.58, but after create with a heat template, the final n

Re: [openstack-dev] [Glance] Core nominations.

Nikhil, If I recall correctly this matter was discussed last time at the start of the L-cycle and at that time we agreed to see if there is change of pattern to later of the cycle. There has not been one and I do not see reason to postpone this again, just for the courtesy of it in the hopes so

[openstack-dev] [Fuel] Deprecation warnings in python-fuelclient-6.1.*

Hi folks! According to the refactoring plan [1] we are going to release the 6.1 version of python-fuelclient which is going to contain recent changes but will keep backwards compatibility with what was before. However, the next major release will bring users the fresh CLI that won’t be compati

Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?

> On Mar 3, 2015, at 8:34 AM, Vishvananda Ishaya wrote: > > I’m pretty sure it has always done this: leave the host set on the final > scheduling attempt. I agree that this could be cleared which would free up > room for future scheduling attempts. > Thanks Vish for the comment. Do we know

[openstack-dev] [Horizon] dependency on non-standardized, private APIs

Guys, I would like discuss a problem which can be seen in Horizon: breaking the boundaries of public, well-specified Object Storage API in favour of utilizing a Swift-specific extensions. Ticket #1297173 [1] may serve as a good example of such violation. It is about relying on non-standard (in the

[openstack-dev] [congress] missing today's meeting

I'm in an all day board meeting. My update is https://launchpad.net/congress/kilo is cleaned up. tagged https://github.com/stackforge/congress/tree/2015.1.0b2 is out. I am still working out getting the tarred file out to http://tarballs.openstack.org/ as part of the process. ~ sean __

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

From: John Griffith [mailto:john.griffi...@gmail.com] Sent: 03 March 2015 14:46 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics]) On Tue,

[openstack-dev] Gerrit tooling improvements(was Re: auto-abandon changesets considered harmful)

I feel the need to abandon changes that seem abandoned. I believe this has been covered to death now, so I'm going to shelve that conversation for a while, and talk about missing tooling in gerrit. One of the examples of something that was auto-abandoned wrongly was a patch on hold until some futu

Re: [openstack-dev] Gerrit tooling improvements(was Re: auto-abandon changesets considered harmful)

On Tue, Mar 3, 2015, at 10:10 AM, Duncan Thomas wrote: > I feel the need to abandon changes that seem abandoned. I believe this > has > been covered to death now, so I'm going to shelve that conversation for a > while, and talk about missing tooling in gerrit. > > One of the examples of somethin

Re: [openstack-dev] [stable] [Glance] Nomination for glance-stable-maint

Nikhil Komawar wrote: > I would like to propose Zhi Yan Liu for the role of stable maintainer > for Glance program. I'll reach out to Zhi Yan to make sure he is aware of the stable branch policy[1], then proceed to add him. [1] https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Ch

Re: [openstack-dev] [nova] what's the merge plan for current proposed microversions?

On 03/03/2015 10:24 AM, Claudiu Belu wrote: > Hello. > > I've talked with Christopher Yeoh yesterday and I've asked him about the > microversions and when will they be able to merge. He said that for now, this > commit had to get in before any other microversions: > https://review.openstack.org

Re: [openstack-dev] [stable] [Glance] Nomination for glance-stable-maint

Thank you, Thierry! -Nikhil From: Thierry Carrez Sent: Tuesday, March 3, 2015 10:26 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [stable] [Glance] Nomination for glance-stable-maint Nikhil Komawar wrote: > I would like to pro

Re: [openstack-dev] Gerrit tooling improvements(was Re: auto-abandon changesets considered harmful)

Right, I think this is the 'procedural -2' case, which feels like we need another state for things that are being held for procedural reasons, which is unrelated to normal code-review. On 03/03/2015 10:10 AM, Duncan Thomas wrote: > I feel the need to abandon changes that seem abandoned. I believe

Re: [openstack-dev] [Horizon] dependency on non-standardized, private APIs

Radoslaw, Unfortunately the documentation for OpenStack has some holes. What you are calling a private API may be something missed in the documentation. Is there a documentation bug on the issue? If not one should be created. In practice OpenStack isn't a specification and implementation. The doc

Re: [openstack-dev] Gerrit tooling improvements(was Re: auto-abandon changesets considered harmful)

On 3 March 2015 at 17:23, Doug Hellmann wrote: > Does the tool ignore patches with Workflow-1 set ("work in progress")? > So if it doesn't then we can easily change it to do so, however, I think a WIP progress patch that hasn't been updated for months counts as abandoned for any sensible purpose

Re: [openstack-dev] [Devstack] Can't start service nova-novncproxy

You have to make sure it's in ENABLED_SERVICES in stackrc. It was removed by default, but then apparently restored via b9f2e25fa8afb2ea17a89ed76c4fac03689b5f07, so if you have that commit, you should be good. Otherwise, you can either add it to the ENABLED_SERVICES variable (either in stackrc,

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

On Tue, Mar 3, 2015 at 8:46 AM, John Griffith wrote: > > > On Tue, Mar 3, 2015 at 7:18 AM, Kuvaja, Erno wrote: > >> > -Original Message- >> > From: Thierry Carrez [mailto:thie...@openstack.org] >> > Sent: 03 March 2015 10:00 >> > To: openstack-dev@lists.openstack.org >> > Subject: Re: [o

Re: [openstack-dev] [nova] what's the merge plan for current proposed microversions?

Hello. I've talked with Christopher Yeoh yesterday and I've asked him about the microversions and when will they be able to merge. He said that for now, this commit had to get in before any other microversions: https://review.openstack.org/#/c/159767/ He also said that he'll double check every

Re: [openstack-dev] Gerrit tooling improvements(was Re: auto-abandon changesets considered harmful)

Sean Dague writes: > Right, I think this is the 'procedural -2' case, which feels like we > need another state for things that are being held for procedural > reasons, which is unrelated to normal code-review. We have been looking into that and believe we may be able to do something like that in

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

John Griffith writes: > ​Should we just rename this thread to "Sensitivity training for > contributors"? I do not think that only new contributors might feel it is negative. I think that both some new and long-time contributors do. My oldest patch is from July -- it's still relevant, just not

[openstack-dev] [devstack]Specific Juno version

Hi, Is there a way to specify the Juno version to be installed using devstack. For now we can only specify stable/juno *git clone -b stable/juno https://github.com/openstack-dev/devstack.git /opt/stack/devstack* but this installs 2014.2.3 which appea

[openstack-dev] Hyper-V Meeting

Hi everyone, We are replacing our CI network infrastructure today.Therefor it is necessary for us to postpone the Hyper-V meeting until next week. p Peter J. Pouliot CISSP Microsoft Enterprise Cloud Solutions C:\OpenStack New England Research & Development Center 1 Memorial Drive Cambridge,

[openstack-dev] [all] cliff 1.10.0 release

The Oslo team is pleased to announce the release of: cliff 1.10.0: Command Line Interface Formulation Framework For more details, please see the git log history below and: https://launchpad.net/python-cliff/+milestone/1.10.0 Please report issues through launchpad: https://bugs.launchpa

Re: [openstack-dev] [devstack]Specific Juno version

You can specify specific tags for each component in your local.conf file, e.g.: NOVA_BRANCH=2014.2 CINDER_BRANCH=2014.2 GLANCE_BRANCH=2014.2 HORIZON_BRANCH=2014.2 KEYSTONE_BRANCH=2014.2 KEYSTONECLIENT_BRANCH=2014.2 NOVACLIENT_BRANCH=2014.2 SWIFT_BRANCH=2014.2 HEAT_BRANCH=2014.2 HTH Alec Fro

[openstack-dev] [all] oslo.config 1.8.0 release

The Oslo team is pleased to announce the release of: oslo.config 1.8.0: Oslo Configuration API For more details, please see the git log history below and: http://launchpad.net/oslo/+milestone/1.8.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo Changes in oslo.

[openstack-dev] [sahara] Reminder: FPF at Mar 5

Hi Sahara folks, FPF [1] will be at Mar 5 and it means that all CRs should be proposed for features and all new features related CRs will need FPF exception to be merged. [1] https://wiki.openstack.org/wiki/FeatureProposalFreeze -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenSta

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

On Tue, Mar 03, 2015 at 09:53:23AM +0100, Miguel Ángel Ajo wrote: > https://review.openstack.org/#/c/159840/1/doc/source/testing/openflow-firewall.rst > > > I may need some help from the OVS experts to answer the questions from > henry.hly. > > Ben, Thomas, could you please? (let me know if

[openstack-dev] [all] oslosphinx 2.5.0 release

The Oslo team is pleased to announce the release of: oslosphinx 2.5.0: OpenStack Sphinx Extensions and Theme For more details, please see the git log history below and: http://launchpad.net/oslosphinx/+milestone/2.5.0 Please report issues through launchpad: http://bugs.launchpad.net/os

Re: [openstack-dev] [Glance] Core nominations.

If it was not clear in my previous message, I would like to again emphasize that I truly appreciate the vigor and intent behind Flavio's proposal. We need to be proactive and keep making the community better in such regards. However, at the same time we need to act fairly, with patience and hav

[openstack-dev] [Fuel][Plugins] Plugins manager as a separate service

Hi, Some time ago we merged a patch [1] for fuel client which allowed to install plugins on the host system, it was a bad design decision because by design fuelclient should work remotely from another machine, but it was a good decision from UX point and there was not time to implement it properly

[openstack-dev] [all] oslo.log 0.4.0 release

The Oslo team is pleased to announce the release of: oslo.log 0.4.0: oslo.log library For more details, please see the git log history below and: http://launchpad.net/oslo.log/+milestone/0.4.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.log Changes in oslo.l

Re: [openstack-dev] [Glance] Core nominations.

So I’m +1 on giving these cores notice and perhaps voting on their removal separately (as was recently done in another project or two). Perhaps the way to compromise here would be to submit a change to the relevant documentation in Glance outlining when a core can be removed (or when the proposal

[openstack-dev] [QA] testing implementation-specific features not covered by OpenStack APIs

As we know Tempest provides many great tests for verification of conformance with OpenStack interfaces - the tempest/api directory is full of such useful stuff. However, regarding the #1422728 ticket [1] (dependency on private HTTP header of Swift), I think we all need to answer for one single but

Re: [openstack-dev] [swift] On Object placement

Hi Christian, Sorry for the slow response. I was looking into the feasibility of your suggestion for Sahara in particular and it took a bit. On 2/19/15, 2:46 AM, "Christian Schwede" wrote: >Hello Jonathan, > >On 18.02.15 18:13, Halterman, Jonathan wrote: 1. Swift should allow authorized se

Re: [openstack-dev] Fw: [nova] Queries regarding how to run test cases of python-client in juno release

On 2/27/2015 1:44 AM, Rattenpal Amandeep wrote: FYI -Forwarded by Rattenpal Amandeep/DEL/TCS on 02/27/2015 01:14PM - To: openstack-dev@lists.openstack.org From: Rattenpal Amandeep/DEL/TCS Date: 02/25/2015 11:43AM Subject: [openstack-dev] [python-novaclient] [python-client] Queries rega

[openstack-dev] [glance] [trove] [heat] [nova] [all] Handling forwarded requests

Hey all, It appears that currently a number of OpenStack services are not generating version catalogs correctly when the service sits behind a proxy. (Reference: https://bugs.launchpad.net/glance/+bug/1384379) Glance already has a fix that was accepted for kilo-1 but it is suboptimal and assumes t

Re: [openstack-dev] [QA] testing implementation-specific features not covered by OpenStack APIs

Hi, I don't see the difference between Swift API and the "well-specified and public Object Storage API v1". If the documentation is not properly documenting the Swift API then we should fix the doc maybe ? Jordan On Tue, Mar 3, 2015 at 5:28 PM, Radoslaw Zarzynski wrote: > As we know Tempest pro

Re: [openstack-dev] [heat][neutron] allowed_address_pairs does not work

While it is entirely possible that the feature is broken, it seems that in this case you're expecting the allowed_address_pairs to populate fixed_ips. Neutron does many crazy and unreasonable things but asking you to pass an attribute in the request to populate another attribute is not one of these

Re: [openstack-dev] [oslo] Graduating oslo.reports: Request to review "clean copy"

On Tue, Feb 24, 2015, at 08:15 PM, Solly Ross wrote: > > > Those scripts have mostly moved into oslotest, so they don't need to be > > synced any more to be used. If you have all of your code, and it follows > > the cookiecutter template, we can look at it and propose post-import > > tweaks. Wh

Re: [openstack-dev] [glance] [trove] [heat] [nova] [all] Handling forwarded requests

Ian, thanks for raising the issue here. The X-Forwarded headers are the standard way to deal with URLs for services behind proxies. I already commented on the Heat proposal to that effect, I think that is the proper way to support services behind proxies. Now in our case, there is also another so

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On Tue, 2015-03-03 at 11:59 +0100, Thierry Carrez wrote: > James Bottomley wrote: > > Actually, this is possible: look at Linux, it freezes for 10 weeks of a > > 12 month release cycle (or 6 weeks of an 8 week one). More on this > > below. > > I'd be careful with comparisons with the Linux kernel

Re: [openstack-dev] [glance] [trove] [heat] [nova] [all] Handling forwarded requests

I made a review in keystone that for this issuehttps://review.openstack.org/#/c/132235/And I got solution from old heat solution - https://review.openstack.org/#/c/64142/ I made it for keystone when we faced with problem that is described in the bug:https://bugs.launchpad.net/keystone/+bug/1370022 

Re: [openstack-dev] Call for mentors - Outreachy (former OPW)

> On Mar 3, 2015, at 3:38 AM, Victoria Martínez de la Cruz > wrote: > > Hi all, > > Next round application deadline for Outreachy is close and and we need > mentors willing to help newcomers to get involved with OpenStack and help > them start contributing [0][1]. > > This would be the 5th

[openstack-dev] [cinder] Decision related to cinder metadata

Hi Stackers, I am referring to one of the action item related to "metadata" discussed here; http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.html Can some help with the final take away (Sorry I could not find any thread related to its decision after this meeting). >F

Re: [openstack-dev] [Manila] Ceph native driver for manila

On Tue, Mar 3, 2015 at 12:51 AM, Luis Pabon wrote: > What is the status on virtfs? I am not sure if it is being maintained. > Does anyone know? > The last i knew its not maintained. Also for what its worth, p9 won't work for windows guest (unless there is a p9 driver for windows ?) if that is p

Re: [openstack-dev] Gerrit tooling improvements

On Tue, 2015-03-03 at 17:10 +0200, Duncan Thomas wrote: > I feel the need to abandon changes that seem abandoned I think there is an agreement that there should be a way to have a clean view of changesets that are being actively worked on, changes where the owner is responding to comments, working

Re: [openstack-dev] [QA] testing implementation-specific features not covered by OpenStack APIs

On 03/03/2015 11:28 AM, Radoslaw Zarzynski wrote: As we know Tempest provides many great tests for verification of conformance with OpenStack interfaces - the tempest/api directory is full of such useful stuff. However, regarding the #1422728 ticket [1] (dependency on private HTTP header of Swift

[openstack-dev] [Ironic] Weekly subteam status report

Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) (As of Mon, 02 Mar 17:00 UTC) Open: 129 (-7) 3 new (-4), 32 in progress (-4), 0 critical, 18 high and 7 incomplete security bug found and fi

Re: [openstack-dev] Gerrit tooling improvements

Is common sense an option here? More specifically I mean leveraging the common sense of both contributors and core reviewers (or whoever is authorized to abandon patches). The formers should abandon patches they're not working on anymore, and expect somebody else to do that if the patches they own

Re: [openstack-dev] [nova] Question about boot-from-volume instance and flavor

On 03/03/2015 01:10 AM, Rui Chen wrote: Hi all, When we boot instance from volume, we find some ambiguous description about flavor root_gb in operations guide, http://docs.openstack.org/openstack-ops/content/flavors.html /Virtual root disk size in gigabytes. This is an ephemeral disk the base i

[openstack-dev] [neutron] The future of Xen + OVS support

There have been a couple of patches [1] [2] proposed to neutron recently that could impact our support for Xen+OVS, but I don’t see an easy way for us to validate such changes. I’m not aware of a 3rd party CI job that runs against Xen, and I don’t know of any active contributors able to manuall

Re: [openstack-dev] [neutron] The future of Xen + OVS support

It might make sense to send this to the users list as well. There may be a large deployment out there with resources willing to at least test changes even if they don't have any upstream development resources. On Tue, Mar 3, 2015 at 12:50 PM, Maru Newby wrote: > There have been a couple of patch

Re: [openstack-dev] [api][all] - Openstack.error common library

On Feb 25, 2015, at 10:47 AM, Doug Hellmann mailto:d...@doughellmann.com>> wrote: On Wed, Feb 25, 2015, at 09:33 AM, Eugeniya Kudryashova wrote: Hi, stackers! As was suggested in topic [1], using an HTTP header was a good solution for communicating common/standardized OpenStack API error codes.

Re: [openstack-dev] [neutron] The future of Xen + OVS support

We certainly care about this but converting the XenServer CI to Neutron+OVS has been hitting a number of issues (notably a few concurrency ones – although there are a few missing features) that we’ve been trying to sort through. I am certainly hoping that we’ll have everything stable enough to s

Re: [openstack-dev] [Fuel][Plugins] Plugins manager as a separate service

Hello, On Tue, Mar 3, 2015 at 6:12 PM, Evgeniy L wrote: > Solution [3] is to implement plugin manager as a separate service > and move all of the complexity there, fuelclient will be able to use > REST API to install/delete/update/downgrade plugins. > In the same way as it's done for OSTF. > I

Re: [openstack-dev] [Fuel] Deprecation warnings in python-fuelclient-6.1.*

Hello, I would vote for 2nd, but i also think that we can generate same information, on merge for example, that will be printed during first run and place it directly in repository (maybe even README?). I guess this is what your 3rd approach is about? So, can we go with both? On Tue, Mar 3,

[openstack-dev] [TripleO] Getting to a 1.0

Hi, Don't let the subject throw you off :) I wasn't sure how to phrase what I wanted to capture in this mail, and that seemed reasonable enough. I wanted to kick off a discussion about what gaps people think are missing from TripleO before we can meet the goal of realistically being able to use T

Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?

On 03/03/2015 06:55 AM, Joe Cropper wrote: On Mar 3, 2015, at 8:34 AM, Vishvananda Ishaya wrote: I’m pretty sure it has always done this: leave the host set on the final scheduling attempt. I agree that this could be cleared which would free up room for future scheduling attempts. Thanks Vish

Re: [openstack-dev] [openstackclient] doodle for meeting time selection

On Thu, Feb 26, 2015 at 3:32 PM, Doug Hellmann wrote: > As we discussed in the meeting today, I’ve created a Doodle to coordinate > a good day and time for future meetings. I picked a bunch of options based > on when it looked like there were IRC rooms obviously available. If none of > these opti

Re: [openstack-dev] [Manila] Ceph native driver for manila

Am 03.03.2015 um 19:31 schrieb Deepak Shetty: [...] >> For us security is very critical, as the performance is too. The >> first solution via ganesha is not what we prefer (to use CephFS >> via p9 and NFS would not perform that well I guess). The second >> solution, to use CephFS directly to the VM

[openstack-dev] [Glance] [all] glance_store release 0.1.12

The glance_store release management team is pleased to announce: glance_store version 0.1.12 has been released on Tuesday March 3rd around 23.51 UTC. For more information, please find the details at: https://launchpad.net/glance-store/+milestone/v0.1.12 Please report the issues through

Re: [openstack-dev] [neutron] The future of Xen + OVS support

> On Mar 3, 2015, at 1:06 PM, Kevin Benton wrote: > > It might make sense to send this to the users list as well. There may be a > large deployment out there with resources willing to at least test changes > even if they don't have any upstream development resources. Good call, I’ve cross-pos

Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs

Added [swift] to topic. On 03/03/2015 07:41 AM, Matthew Farina wrote: Radoslaw, Unfortunately the documentation for OpenStack has some holes. What you are calling a private API may be something missed in the documentation. Is there a documentation bug on the issue? If not one should be created.

Re: [openstack-dev] [neutron] The future of Xen + OVS support

> On Mar 3, 2015, at 1:44 PM, Bob Ball wrote: > > We certainly care about this but converting the XenServer CI to Neutron+OVS > has been hitting a number of issues (notably a few concurrency ones – > although there are a few missing features) that we’ve been trying to sort > through. > > I

Re: [openstack-dev] Call for mentors - Outreachy (former OPW)

@Christian I'm so glad to hear you are interested! I'm adding more details below :) @John Thanks for sharing your experience! It's great to know that both you and mahatic enjoyed the internship So, more details about the internship For mentees, >From March 3rd to March 24th mentees have time to

[openstack-dev] [all][log][api] Reminder: Log Working Group meeting 3/4/2015 -- Wednesday 20:00UTC

Log Working Group is a cross project (horizontal) and community group that is working to rationalize log messages and logging practices across the OpenStack ecosystem. This has been identified as a big concern within the user communities. Anyone with an interest in improving logs, logging and

Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?

Logged a bug [1] and submitted a fix [2]. Review away! [1] https://bugs.launchpad.net/nova/+bug/1427944 [2] https://review.openstack.org/#/c/161069/ - Joe > On Mar 3, 2015, at 4:42 PM, Jay Pipes wrote: > > On 03/03/2015 06:55 AM, Joe Cropper wrote: >>> On Mar 3, 2015, at 8:34 AM, Vishvananda

[openstack-dev] [QA] Meeting Thursday March 5th at 22:00 UTC

Hi everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be Thursday, March 5th at 22:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add an item to the

Re: [openstack-dev] [nova] Question about boot-from-volume instance and flavor

Thank you for reply, @Jay. +1 for There should not be any "magic" setting for root_gb that needs to be interpreted both by the user and the Nova code base. I will try to restart the patch 136284 on the other way, like: instance object. Best Regards 2015-03-04 4:45 GMT+08:00 Jay Pipes : > On 03

[openstack-dev] [nova] blueprint about multiple workers supported in nova-scheduler

Hi all, I want to make it easy to launch a bunch of scheduler processes on a host, multiple scheduler workers will make use of multiple processors of host and enhance the performance of nova-scheduler. I had registered a blueprint and commit a patch to implement it. https://blueprints.launchpad.n

Re: [openstack-dev] [Manila] Ceph native driver for manila

On Wed, Mar 4, 2015 at 5:10 AM, Danny Al-Gaaf wrote: > Am 03.03.2015 um 19:31 schrieb Deepak Shetty: > [...] > >> For us security is very critical, as the performance is too. The > >> first solution via ganesha is not what we prefer (to use CephFS > >> via p9 and NFS would not perform that well I

[openstack-dev] [oslo_messaging]Notification listener for nova

Hi, I'm trying to listen to events of type "compute.instance.*" (e.g. compute.instance.update). I tried the following code: from oslo_config import cfg import oslo_messaging class NotificationEndpoint(object): filter_rule = oslo_messaging.NotificationFilter(publisher_id='compute.*', event_ty

Re: [openstack-dev] Need help in configuring keystone

Hi Marek, I tried with the auto-generated shibboleth2.xml, just added the application override attribute, now im stuck with looping issue, when i access v3/OS-FEDERATION/identity_providers/idp_2/protocols/saml2/auth for the first time it is prompting for username and password once provided it go

Re: [openstack-dev] [Devstack] Can't start service nova-novncproxy

After update my devstack to obtain b9f2e25fa8afb2ea17a89ed76c4fac03689b5f07, it works now. Thanks very much. -chen -Original Message- From: Solly Ross [mailto:sr...@redhat.com] Sent: Tuesday, March 03, 2015 11:48 PM To: OpenStack Development Mailing List (not for usage questions) Subje