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 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] [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

-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] 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] [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] [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] (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

[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] [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

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] [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] [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

[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] [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

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] [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] [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] [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] [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] [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, 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] [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] [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] [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] [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

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] [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 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] [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] 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] [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

[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 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

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] [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

[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] [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

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] [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/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] [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] [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] 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] [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

[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] [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

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

[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] [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

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

[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:

<    1   2