[openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

Hi, QA folks! As ironic-inspector is joining the openstack/* crows, we're faces with integration testing question. At the summit we discussed with Devananda that it makes sense for inspector + ironic integration test to live in tempest with other bare metal tests. However, judging by https:

Re: [openstack-dev] OpenStack Diversity Working Group

Hi all, Thanks for starting this! I'd like to join you for the kick off meeting. In which timezone are the times in the Doodle? Cheers, Victoria 2015-06-09 17:28 GMT-03:00 Sousou, Imad : > Stackers – We’re happy to announce the creation of a Diversity Working > Group. The genesis for this wor

Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x

Hi Mike, Thanks a lot for your quick reply which is very useful to me. On 06/09/2015 07:08 PM, Mike Bayer wrote: > On 6/9/15 9:26 AM, Thomas Goirand wrote: >> Hi, >> >> The python-sqlalchemy package has been uploaded to Debian Experimental, >> and is about to be uploaded to Debian Unstable. So I

[openstack-dev] ThirdPartyCI: Tempest job fails with "Unexpected termination of the channel"

Short story: - all runs of the tempest job are failing after ~ 1,5 - 2 hrs with "FATAL: java.io.IOException: Unexpected termination of the channel" and jenkins logs "SEVERE: I/O error in channel d-p-c-local_01-1655 java.io.IOException: Unexpected termination of the channel" Long story: - Host is

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

Hi Dmitry, 2015-06-10 16:11 GMT+09:00 Dmitry Tantsur : > Hi, QA folks! > > As ironic-inspector is joining the openstack/* crows, we're faces with > integration testing question. At the summit we discussed with Devananda that > it makes sense for inspector + ironic integration test to live in tempe

Re: [openstack-dev] [all][api] 1 new guideline entering freeze period

michael mccune wrote: > The API working group has one new guidelines that is entering the freeze > period. We would like to ask all PTLs and CPLs, and other interested > parties, to take a look at these reviews. We will use lazy consensus at > the end of the freeze to merge them if there are no obj

[openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

Hello Manila, There is a HDFS driver in Manila summited by our team in Kilo, so I guess we do own this driver in Manila for current situation. But, CI systems are really new to us, and we heard from other teams that they took almost one year to implement a CI for going through all the company

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote: Hi Dmitry, 2015-06-10 16:11 GMT+09:00 Dmitry Tantsur : Hi, QA folks! As ironic-inspector is joining the openstack/* crows, we're faces with integration testing question. At the summit we discussed with Devananda that it makes sense for inspector

Re: [openstack-dev] ThirdPartyCI: Tempest job fails with "Unexpected termination of the channel"

Can you check dmesg –T to see at least if the messages are not too old? Are you using port2 as a connection to VM? Lenny Verkhovsky From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com] Sent: Wednesday, June 10, 2015 10:34 AM To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 27/05/15 10:14, Thomas Goirand wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, tl;dr: - - We'd like to push distribution packaging of OpenStack on upstream gerrit with reviews. - - The intention is to better share the workload, and improve the overall QA for packaging *and* up

Re: [openstack-dev] [Nova] Liberty Priorties for Nova

On Wed, Jun 10, 2015 at 08:48:36AM +0200, Andreas Scheuring wrote: > Daniel, > if I got it right, the vif script blueprint only is about plug/unplug > operations and not about generating new xml representations for vif > types. What if for a new vif type it's sufficient to have the > get_config_*

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 06/09/2015 04:54 PM, Jeremy Stanley wrote: > On 2015-06-09 10:55:55 +0200 (+0200), Thomas Goirand wrote: > [...] >> That's far from being in place. Also, while we are removing point >> releases, and support for Icehouse, we still don't have a common private >> Gerrit for security, which we've be

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

As a further data point, Neutron has been trying to introduce microversioning for a while, without success so far. Given the sheer amount of backends the management layer integrates with, and the constant need for the various subteams to "experiment" with the API, the proposal [1] has probably som

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 06/05/2015 02:46 PM, Thierry Carrez wrote: > So.. summarizing the various options again: > > Plan A > Just drop stable point releases. > (-) No more release notes > (-) Lack of reference points to compare installations > > Plan B > Push date-based tags across supported projects from time to ti

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

2015-06-10 16:48 GMT+09:00 Dmitry Tantsur : > On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote: >> To solve it, we have decided the scope of Tempest as the etherpad >> mentioned. >> >>> Are there any hints now on where we can start with our integration tests? >> >> >> For the other projects, we are m

[openstack-dev] doubt about static routes and host routes

Hi, Can we add static routes to the router which created by "#neutron router-create" command ? What is the defference static routes of router and --host_routes of subnet ? I also would like to know use case of static routes of router and --host_routes of subnet ? Regards Saju Madhavan +91 09535

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 10 June 2015 at 09:53, Thomas Goirand wrote: > On 06/05/2015 02:46 PM, Thierry Carrez wrote: >> So.. summarizing the various options again: >> >> Plan A >> Just drop stable point releases. >> (-) No more release notes >> (-) Lack of reference points to compare installations >> >> Plan B >> Push

Re: [openstack-dev] [all][python3] use of six.iteritems()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/10/2015 02:15 AM, Robert Collins wrote: > I'm very glad folk are working on Python3 ports. > > I'd like to call attention to one little wart in that process: I > get the feeling that folk are applying a massive regex to find > things like d.it

Re: [openstack-dev] [all][python3] use of six.iteritems()

On 10 June 2015 at 17:22, gordon chung wrote: > maybe the suggestion should be "don't blindly apply six.iteritems or items" > rather than don't apply iteritems at all. admittedly, it's a massive eyesore, > but it's a very real use case that some projects deal with large data results > and to en

[openstack-dev] [rabbitmq] ANN New ops-oriented guides on rabbitmq.com

First of all, apologies if this belongs strictly to openstack-docs, based on multiple discussions in Vancouver I'd like more people to be aware of this. As announced in April and at the summit in May, RabbitMQ team at Pivotal  would like to help with OpenStack documentation and operations experie

Re: [openstack-dev] [all][python3] use of six.iteritems()

On 10 June 2015 at 21:30, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 06/10/2015 02:15 AM, Robert Collins wrote: >> I'm very glad folk are working on Python3 ports. >> >> I'd like to call attention to one little wart in that process: I >> get the feeling that

Re: [openstack-dev] doubt about static routes and host routes

Yes, static routes can be added to the router: https://ask.openstack.org/en/question/42529/how-to-add-extra-static-route-in-neutron-havana/ host_routes are routes advertised to the clients via DHCP, they don't apply to the router. >I also would like to know use case of static routes of router and

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

Dmitry, If you chose to use Rally framework for testing there are 3 opportunities: - Keep Rally plugins (tests) in separated tree - Keep Rally plugins (tests) in your project tree - Keep Rally plugins (tests) in Rally repo Rally plugins can be used for all kinds of testing: (perf, scalability

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 10 June 2015 at 20:12, Matthias Runge wrote: > Since our software is to be consumed by packages, shouldn't the packages > project consider itself to be responsible for global requirements? I.e. > checking, if requirements are packageable, if versions fit, etc. I think we welcome input from di

Re: [openstack-dev] [oslo] oslo releasing is noisy...

Le 09/06/2015 18:31, Thierry Carrez a écrit : We are currently exploring the option to repurpose the openstack-announce ML to be the extensive record of release announcements. It's part of a larger plan to streamline library releases, about which Doug should start a discussion pretty soon now.

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 10 June 2015 at 11:07, Robert Collins wrote: > On 10 June 2015 at 20:12, Matthias Runge wrote: > >> Since our software is to be consumed by packages, shouldn't the packages >> project consider itself to be responsible for global requirements? I.e. >> checking, if requirements are packageable,

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

On 06/10/2015 11:57 AM, Boris Pavlovic wrote: Dmitry, If you chose to use Rally framework for testing there are 3 opportunities: - Keep Rally plugins (tests) in separated tree - Keep Rally plugins (tests) in your project tree - Keep Rally plugins (tests) in Rally repo Rally plugins can b

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

Hi Derek, > I selected these 80 to move all of what RDO is currently maintaining on > gerrithub to review.openstack.org, this was perhaps too big a set and in RDO > we instead may need to go hybrid. Yeah, In my opinion we ahve lots of repeated divergence between the different python modules, so g

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 10/06/15 12:07, Robert Collins wrote: On 10 June 2015 at 20:12, Matthias Runge wrote: Since our software is to be consumed by packages, shouldn't the packages project consider itself to be responsible for global requirements? I.e. checking, if requirements are packageable, if versions fit,

Re: [openstack-dev] [QA] [Ironic] [Inspector] Where should integration tests for non-core projects live now? (Was: Toward 2.0.0 release)

Dmitry, We introduced recently dsvm rally ironic job: https://review.openstack.org/#/c/187997/ Now we are working on Rally tests for Ironic: https://review.openstack.org/#/c/186064/ Don't hesitate to join us=) Best regards, Boris Pavlovic On Wed, Jun 10, 2015 at 1:23 PM, Dmitry Tantsur wrote:

Re: [openstack-dev] [murano] shellcheck all .sh scripts in murano-deployment

Hi, I'm using shellcheck during automation scripts writing as linter and I believe that incorporation of this tool for additional verification in CI is good idea. Thanks, Igor Yozhikov Senior Deployment Engineer at Mirantis skype: igor.yozhikov cellular: +7 901 5331200 s

Re: [openstack-dev] [all][python3] use of six.iteritems()

On 06/09/2015 08:15 PM, Robert Collins wrote: > I'm very glad folk are working on Python3 ports. > > I'd like to call attention to one little wart in that process: I get > the feeling that folk are applying a massive regex to find things like > d.iteritems() and convert that to six.iteritems(d). >

Re: [openstack-dev] [murano] shellcheck all .sh scripts in murano-deployment

Hi Kirill, +1 from my side, shellcheck + bashate can help to increase quality of CI scripts. On Wed, Jun 10, 2015 at 2:19 PM, Igor Yozhikov wrote: > Hi, I'm using shellcheck during automation scripts writing as linter and I > believe that incorporation of this tool for additional verification i

Re: [openstack-dev] [murano] shellcheck all .sh scripts in murano-deployment

+1, nice idea. Shell script are not easy to review - large files, not covered by unit tests. Any automatic tool could be beneficial. Regards Filip On 06/09/2015 09:58 PM, Kirill Zaitsev wrote: Folks, I’ve got another proposal, mainly to the guys, who deal with CI and test jobs daily. What wo

Re: [openstack-dev] [release][oslo] oslotest release 1.7.0 (liberty)

Hi All, this oslotest release break oslo.messaging gate - unittest fails with ImportError, on import mox from six.moves - [0]. It caused by commit [1], which removed adding mox to six moves. There is a fix for oslo.messaging - [2] - please, help to merge it. [0] - http://paste.openstack.org/show

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

Excerpts from Matthias Runge's message of 2015-06-10 12:29:45 +0200: > On 10/06/15 12:07, Robert Collins wrote: > > On 10 June 2015 at 20:12, Matthias Runge wrote: > > > >> Since our software is to be consumed by packages, shouldn't the packages > >> project consider itself to be responsible for g

Re: [openstack-dev] [Barbican] Multiple KMIP servers on a single barbican

You would need to update the KMIPSecretStore or create a new SecretStore to handle this. The logic should be behind the SecretStore abstraction because Barbican only allows one active secret store. I would think that the configuration file would have a listing of available KMIP server URLs. The U

Re: [openstack-dev] [murano] shellcheck all .sh scripts in murano-deployment

On 2015-06-10 13:48:26 +0200 (+0200), Filip Blaha wrote: > +1, nice idea. Shell script are not easy to review - large files, not > covered by unit tests. Any automatic tool could be beneficial. It's worth noting that just because your shell scripts don't have their own validation tests doesn't mea

[openstack-dev] Enabling an Open Cloud with OpenStack

Dear OpenStack community, The short version: We are proposing a new set of use cases for OpenStack and a set of changes to enable a multi-landlord cloud model, where multiple service providers can cooperate (and compete) to stand up services in a single cloud. We had great feedback from the comm

Re: [openstack-dev] [oslo] oslo releasing is noisy...

Victor Stinner wrote: > Le 09/06/2015 18:31, Thierry Carrez a écrit : >> We are currently exploring the option to repurpose the >> openstack-announce ML to be the extensive record of release >> announcements. It's part of a larger plan to streamline library >> releases, about which Doug should star

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

Dave Walker wrote: > On 10 June 2015 at 09:53, Thomas Goirand wrote: >>> What would be your preferred option ? >> >> I see no point of doing D. I already don't use tarballs, and those who >> do could as well switch to generating them (how hard is it to run >> "python setup.py sdist" or "git archiv

Re: [openstack-dev] (re)centralizing library release management

On 06/09/2015 01:25 PM, Doug Hellmann wrote: Until now we have encouraged project teams to prepare their own library releases as new versions of projects were needed. We've started running into a couple of problems with that, with releases not coming often enough, or at a bad time in the release

Re: [openstack-dev] [release][oslo] oslotest release 1.7.0 (liberty)

Good news: your fix is already merged into oslo.messaging ;-) oslo.messaging now uses directly mox3, on Python 2 and Python 3. Victor Le 10/06/2015 14:04, Victor Sergeyev a écrit : Hi All, this oslotest release break oslo.messaging gate - unittest fails with ImportError, on import mox from si

[openstack-dev] [cinder][nova] Is volume connection_info modeled/documented anywhere?

While investigating/discussing bug 1463525 [1] I remembered how little I know about what can actually come out of the connection_info dict returned from the os-initialize_connection cinder API call. So we added some debug logging in nova and I remembered that there are potentially credentials

Re: [openstack-dev] (re)centralizing library release management

Paul Belanger wrote: > While I haven't participated in release management before, I'd like to > volunteer my services to help. Where is the best place (IRC) to > collaborate? I would encourage prospective release managers to join #openstack-relmgr-office where Doug and I discuss that sort of thing

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/10/2015 12:25 PM, Dave Walker wrote: > The initial core reviewers was seeded by representatives of distro's and > vendors to get their input on viability in distro's. Really? James, were you made core on the requirements? I once tried to follow the requirements repo, though it moves too fas

Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs

On Tue, Jun 09, 2015 at 05:21:18PM EDT, Kevin Benton wrote: > I wasn't planning on wiping them out for now since I'm leveraging a lot of > the extension loading that exists so someone can remove the namespaces if > they want. OK - I'll take it on if there's no objections -- Sean M. Collins

Re: [openstack-dev] Enabling an Open Cloud with OpenStack

Hi Orran, We also have a project called Tricircle that aim to solve similar problem, but with a different approach with Mercador. You and your team are more than welcome to join the discussion we will hold in Tricircle Meeting. See the details at https://www.mail-archive.com/openstack-dev@lists.o

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/06/15 15:12, Thomas Goirand wrote: >> The initial core reviewers was seeded by representatives of >> distro's and >>> vendors to get their input on viability in distro's. > Really? James, were you made core on the requirements? Believe it or n

Re: [openstack-dev] [cinder][nova] Is volume connection_info modeled/documented anywhere?

I don't think you need an entry per driver, you need an entry per connection type - iSCSI, FC, DRDB, CEPH being the ones I can think of off the top of my head On 10 Jun 2015 16:57, "Matt Riedemann" wrote: > While investigating/discussing bug 1463525 [1] I remembered how little I > know about what

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 10 June 2015 at 15:12, Thomas Goirand wrote: > On 06/10/2015 12:25 PM, Dave Walker wrote: >> The initial core reviewers was seeded by representatives of distro's and >> vendors to get their input on viability in distro's. > > Really? James, were you made core on the requirements? > > I once tri

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 6/10/15, 09:12, "Thomas Goirand" wrote: >On 06/10/2015 12:25 PM, Dave Walker wrote: >> The initial core reviewers was seeded by representatives of distro's and >> vendors to get their input on viability in distro's. > >Really? James, were you made core on the requirements? > >I once tried to

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On Wed, Jun 10, 2015 at 5:24 PM, Ian Cordasco wrote: > > > On 6/10/15, 09:12, "Thomas Goirand" wrote: > > >On 06/10/2015 12:25 PM, Dave Walker wrote: > >> The initial core reviewers was seeded by representatives of distro's and > >> vendors to get their input on viability in distro's. > > > >Rea

[openstack-dev] [neutron][fwaas] FWaaS IRC meetings to happen alternate Wed (no mtg today).

Hi All: Just a reminder to FWaaS meeting attendees, as discussed in last weeks FWaaS IRC [1], with all the PTO’s going on and the need for time to build up on the SG alignment discussions – it was felt that it would be good to go to an alternate week format. So the next meeting will be on Jun 1

Re: [openstack-dev] [cinder][nova] Is volume connection_info modeled/documented anywhere?

On Wed, Jun 10, 2015 at 7:54 AM, Matt Riedemann wrote: > While investigating/discussing bug 1463525 [1] I remembered how little I > know about what can actually come out of the connection_info dict returned > from the os-initialize_connection cinder API call. > > So we added some debug logging in

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

Hi Chen, You can ask if OpenStack Infrastructure team can set up CI for this driver. They have set up CI's for a few Cinder drivers based on open source storage systems. Thanks, Xing From: Li, Chen [mailto:chen...@intel.com] Sent: Wednesday, June 10, 2015 3:48 AM To: OpenStack Development Ma

[openstack-dev] [nova] vif type libvirt-network

Hi Daniel, Neil and others, I was thinking about introducing libvirt-network as a new vif type to nova. It can be used when Neutron prepares a libvirt network for attaching guests. Would you see any general concerns with such an approach? Anything that I need to consider with libvirt networks in

Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x

On 6/10/15 3:26 AM, Thomas Goirand wrote: Hi Mike, Thanks a lot for your quick reply which is very useful to me. On 06/09/2015 07:08 PM, Mike Bayer wrote: On 6/9/15 9:26 AM, Thomas Goirand wrote: Hi, The python-sqlalchemy package has been uploaded to Debian Experimental, and is about to be

Re: [openstack-dev] [murano] shellcheck all .sh scripts in murano-deployment

Thanks for comment and suggestion! there is also shutil2 framework for unit testing over shell scripts. We shall consider it whether it could bring us value for the effort. I personally have no strong opinion about that. Little contradiction to my previous mail:-) Regards Filip On 06/10/2

Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

There are two classes of behavior that need to be handled: 1) There are things that can only be done after forking like setting up connections or spawning threads. 2) Some things should only be done once regardless of number of forks, like syncing. Even when you just want something to happen on

Re: [openstack-dev] [javascript] Linters

On Tue, Jun 9, 2015 at 3:37 PM Robert Collins wrote: > On 10 June 2015 at 04:01, Michael Krotscheck wrote: > > Well, it looks like everyone has disqualified jslint and jshint, so let's > > just make a decision there and remove them from the running. Unless I > hear a > > compelling reason to use

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

Hello folks, Thanks for the consideration of this feature. Does it seem realistic for a Liberty release of Keystone middleware to expose X-Group-Ids, or would this be an M and beyond sort of thing? Thanks, John From: Henry Nash mailto:henryna...@mac.com>> Reply-To: "OpenStack Development Mail

[openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick

This is a follow-on to the thread [1] asking about modeling the connection_info dict returned from the os-initialize_connection API. The more I think about modeling that in Nova, the more I think it should really be modeled in Cinder with an oslo.versionedobject since it is an API contract wit

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

On 2015-06-10 14:39:46 + (+), yang, xing wrote: > You can ask if OpenStack Infrastructure team can set up CI for > this driver. They have set up CI's for a few Cinder drivers based > on open source storage systems. To be fair, the Infra team hasn't really written the jobs to test those, bu

Re: [openstack-dev] Openstack Diversity Working Group

The Doodle time zone doesn't seem to be appearing in the local timebased upon the viewer. Sorry - The time zone is US/Pacific time (UTC-7), you'll need to do your own conversion. Thanks Carol From: Sousou, Imad [mailto:imad.sou...@intel.com] Sent: Tuesday, June 09, 2015 11:34 AM To: foundat...

Re: [openstack-dev] [Nova] Liberty Process, Deadlines and Dates for Nova

On 4 June 2015 at 12:42, John Garbutt wrote: > Hi, > > Following up from nova-meetings and this summit session: > https://etherpad.openstack.org/p/YVR-nova-liberty-process > With that in mind, does this seem like a good idea? > June 12: spec review day (to be confirmed) Note this is happening

Re: [openstack-dev] [OpenStack Foundation] Openstack Diversity Working Group

If anyone needs help with the timezone conversion, I recommend http://www.timeanddate.com/worldclock/meeting.html Just put in "Portland" and your nearest city into the boxes and you'll get an hour-by-hour breakdown :) On 10/06/15 23:39, Barrett, Carol L wrote: > The Doodle time zone doesn’t seem

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

We're aiming for a Spec "Proposal" Freeze deadline for Liberty of June 23rd, but are requiring that specs are approved by our spec reviewers by that date. The spec [1] is currently pretty straightforward and provides us several benefits, so I don't expect it to be a complicated process, but is curr

Re: [openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick

On Wed, Jun 10, 2015 at 10:40:02AM -0500, Matt Riedemann wrote: > This is a follow-on to the thread [1] asking about modeling the > connection_info dict returned from the os-initialize_connection API. > > The more I think about modeling that in Nova, the more I think it should > really be modeled

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

So... as an op, without release notes, how am I supposed to figure out the proper upgrade procedure's when you often have to lockstep, in the right order, nova+neutron upgrades (or other project combinations)? Thanks, Kevin From: Thomas Goirand [z...@debi

[openstack-dev] Announcing Gertty 1.2.0

Announcing Gertty 1.2.0 === Gertty is a console-based interface to the Gerrit Code Review system. Gertty is designed to support a workflow similar to reading network news or mail. It syncs information from Gerrit to local storage to support disconnected operation and easy man

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

On 10 June 2015 at 17:06, Fox, Kevin M wrote: > So... as an op, without release notes, how am I supposed to figure out the > proper upgrade procedure's when you often have to lockstep, in the right > order, nova+neutron upgrades (or other project combinations)? > > Thanks, > Kevin Hi Kevin, I

[openstack-dev] [murano] backporting changes to stable/juno and stable/kilo

Hi all. I’ve been looking through the bugs/fixes we’ve made during kilo cycle. Some of them are worthy of being backported to stable/juno. And some of the fixes we’ve already made in liberty are worthy of being backported to stable/kilo. Since we’ve agreed on using tags for bugs I’ve marked tho

Re: [openstack-dev] [ceilometer] polling agent configuration speculation

On Tue, 9 Jun 2015, Luo Gangyi wrote: In current, ceilometer load pollsters by agent namespace, So do you mean you want load pollsters one by one through their name(maybe defined in pipeline.yaml)? If loading all pollsters in one time do not cost much, I think your change is bit unnecessary. Bu

Re: [openstack-dev] [Keystone] Midcycle

Hi Adam, Do you have any more information on the Boston University dorm situation? On Tue, Jun 9, 2015 at 1:25 PM, Adam Young wrote: > Keystone Liberty Midcycle Meetup > > Time and Location > > When: July 15-17 (Wed-Fri) > > Where: Boston University, Boston, MA, USA > > > Keystone Midcycle Wi

Re: [openstack-dev] [ceilometer] polling agent configuration speculation

On Tue, 9 Jun 2015, gordon chung wrote: i still like the idea of splitting polling and processing task. pros: - it moves load off poll agents and onto notificaiton agent - we essentially get free healthcheck events by doing this con: to play devil's advocate. the one down side is that now ther

Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC

After some upstream discussion, moving the meeting from 1600 to 1700 UTC does not seem very popular. It was brought up that changing the time to 16:30 UTC could accommodate more people. For the people that attend the 1600 UTC meeting time slot can you post further feedback to address this? Tha

Re: [openstack-dev] [Openstack] [OpenStack Foundation] Openstack Diversity Working Group

Doodle does this automatically. At least it presented me with what appeared to be US East times. There is a box on the upper right that tells you the time zone and lets you change it. Pete On Wed, 2015-06-10 at 23:43 +0800, Tom Fifield wrote: > If anyone needs help with the timezone conversion,

[openstack-dev] [ops][tags][packaging] ops:packaging tag - a little common sense, please

Cross-posting to -operators and -dev because this involves *packagers* of OpenStack, as well as operators who use those packages. Hello Operators, First, let me start out by saying if you were offended by my snarky comments at yesterday's TC meeting [1] regarding the direction of the Ops Tags

Re: [openstack-dev] [ops][tags][packaging] ops:packaging tag - a little common sense, please

Jay Pipes wrote: In short, I would love it if the Ops Tags team would stick with binary tag definitions -- a tag should mean one thing and one thing only. I absolutely agree Jay. I think the path that is currently being pursued adds a lot of challenges without appropriate offsetting benefits.

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

Thanks Jeremy. I assume Chen could follow this example to add a job for the HDFS driver? https://review.openstack.org/#/c/188744/ Thanks, Xing -Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: Wednesday, June 10, 2015 11:40 AM To: OpenStack Development Mailing

Re: [openstack-dev] [Ironic] weekly meetings and sub-team reports and people

On Tue, Jun 09, 2015 at 04:33:41PM -0400, Ruby Loo wrote: > Hi, > > I noticed (from reading the logs[1]) that there weren't many folks in this > week's weekly meeting. And no cores attended. And the sub-team reports (in > our etherpad[2]) were woefully lacking. I guess that means only driver > dev

Re: [openstack-dev] [javascript] Linters

On 11 June 2015 at 03:29, Michael Krotscheck wrote: > > > On Tue, Jun 9, 2015 at 3:37 PM Robert Collins > wrote: > There are two package managers in the JavaScript world right now, one that > focuses on node.js/server dependencies (karma, lint, express, etc), and one > that focuses on in-browser

Re: [openstack-dev] [cinder][nova] modeling connection_info with a versioned object in os-brick

On 06/10/2015 08:40 AM, Matt Riedemann wrote: This is a follow-on to the thread [1] asking about modeling the connection_info dict returned from the os-initialize_connection API. The more I think about modeling that in Nova, the more I think it should really be modeled in Cinder with an oslo.v

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

On 2015-06-10 18:20:24 + (+), yang, xing wrote: > Thanks Jeremy. I assume Chen could follow this example to add a > job for the HDFS driver? > > https://review.openstack.org/#/c/188744/ That's a fine short-form answer. The longer answer is to solicit input from some of the people who hav

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

Hi Dave, Ah, I did misunderstand. Thanks for clarifying. Kevin From: Dave Walker [em...@daviey.com] Sent: Wednesday, June 10, 2015 9:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [stable] No longe

[openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

Folks, As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to propose Brian Haley as a member of the Neutron L3 core reviewer team. Brian has been a long time contributor in Neutron showing expertise particularly in IPv6, iptables, and Linux kernel matters. His knowledge and involvemen

Re: [openstack-dev] [nova] vif type libvirt-network

On 10/06/15 15:47, Andreas Scheuring wrote: Hi Daniel, Neil and others, I was thinking about introducing libvirt-network as a new vif type to nova. It can be used when Neutron prepares a libvirt network for attaching guests. Would you see any general concerns with such an approach? Anything tha

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

On Wed, Jun 10, 2015 at 2:11 PM, Carl Baldwin wrote: > Folks, > > As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to > propose Brian Haley as a member of the Neutron L3 core reviewer team. > Brian has been a long time contributor in Neutron showing expertise > particularly in IPv6,

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

+1 - Original Message - > Folks, > > As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to > propose Brian Haley as a member of the Neutron L3 core reviewer team. > Brian has been a long time contributor in Neutron showing expertise > particularly in IPv6, iptables, and Linux

Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

On 08/06/15 22:02, Kevin Benton wrote: This depends on what initialize is supposed to be doing. If it's just a one-time sync with a back-end, then I think calling it once in each child process might not be what we want. I left a comment on Terry's patch. I think we should just use the callback

Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

On Wed, Jun 10, 2015 at 2:25 PM, Neil Jerram wrote: > > > On 08/06/15 22:02, Kevin Benton wrote: > >> This depends on what initialize is supposed to be doing. If it's just a >> one-time sync with a back-end, then I think calling it once in each >> child process might not be what we want. >> >> I

Re: [openstack-dev] [Openstack-operators] [ops][tags][packaging] [tc] ops:packaging tag - a little common sense, please

Forgive the top posting. Thank you Jay for your clarification and apology. I wrote the piece below **before** you sent out your email this afternoon, so again this is nothing personal and not targeted at any **specific** person. With that said, I still think that what I have to say is still

Re: [openstack-dev] [nova] vif type libvirt-network

I don't see a problem with this, though I think you do want plug/unplug calls to be passed on to Neutron so that has the opportunity to set up the binding from its side (usage >0) and tear it down when you're done with it (usage <1). There may be a set of races you need to deal with, too - what ha

[openstack-dev] Online Migrations.

All, I am taking over work on https://review.openstack.org/#/c/154521/ from Johanness and have spent some time today discussing the current patchset and what is remaining with Dan and Johannes. I wanted to broach the topic of the remaining development with the lists to make sure we go in the

[openstack-dev] [oslo] Adopt mox3

Oslo folks, everyone, mox3 needs to be maintained since some of our projects use it and we have it in our global requirements. Here's the proposal from Doug - https://review.openstack.org/#/c/190330/ Any objections? Please chime in here or on the review. thanks, dims -- Davanum Srinivas :: ht

Re: [openstack-dev] [openstack-operators][openstack][chef] Pre-release of knife-openstack is out (1.2.0.rc1)

> On Jun 4, 2015, at 6:12 PM, JJ Asghar wrote: > > I have cut a new release of the knife-openstack[1] gem today. We have a > couple new features[2] which has been asked for a while. I have pushed another pre-release (1.2.0.rc2) of knife-openstack. The main change is support for the `—bootst

Re: [openstack-dev] [nova] vif type libvirt-network

Hi Ian, Thanks for your reply! On 10/06/15 21:07, Ian Wells wrote: I don't see a problem with this, though I think you do want plug/unplug calls to be passed on to Neutron so that has the opportunity to set up the binding from its side (usage >0) and tear it down when you're done with it (usage

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

+1 Brian will be a great addition for L3 On Wed, Jun 10, 2015, Carl Baldwin wrote: > Folks, > > As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to > propose Brian Haley as a member of the Neutron L3 core reviewer team. > Brian has been a long time contributor in Neutron showing ex

Re: [openstack-dev] Online Migrations.

> The remaining work is to have a way of preventing database contracts > from running until data migrations that the column interacts with are > complete, this is not an easy problem to solve as the goal of the > online migrations is to do pure model based schema migrations and > there is no way of

  1   2   >