Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

That was my feeling Moshe, thanks for checking. Anil, which card and drivers are you using exactly? You should probably contact your card vendor and check if they have a fix for the issue, which seems more like a bug on their implementation of the embedded switch, the card or the driver. Best

Re: [openstack-dev] [nova] os-capabilities library created

On Wed, Aug 03, 2016 at 07:47:37PM -0400, Jay Pipes wrote: > Hi Novas and anyone interested in how to represent capabilities in a > consistent fashion. > > I spent an hour creating a new os-capabilities Python library this evening: > > http://github.com/jaypipes/os-capabilities > > Please see

[openstack-dev] [neutron][taas] : Return VLAN ID for tap-service

When we create a tap-service, a VLAN ID will be associated with that tap-service. In case we want to identify the flows associated with that VLAN ID, so that we can add additional filters, the response returned after creating a tap-service must include the VLAN ID information as well. Can this be

[openstack-dev] [release] Branching Gnocchi stable/2.2

Hi release team, I've asked on IRC, but I guess it's safer on the ml. We tagged Gnocchi 2.2.0 using the release repo, but as discussed earlier on this list, the branching system is not ready yet. So we'd need someone on your side to cut a stable/2.2 branch starting at the 2.2.0 tag. Thanks!

[openstack-dev] [Kuryr] Overlay MTU setup in docker remote driver

Hi Kuryr team, When the network in neutron using overlay for vm, it will use dhcp option to control the VM interface MTU, but for docker, the ip address does not get from dhcp. So it will not set up proper MTU in container. Two work-around in my mind now: 1. Set the default MTU in docker to 1450

Re: [openstack-dev] [Zun][Higgins] Proposing Sudipta Biswas and Wenzhi Yu for Zun core reviewer team

+1 for both, they would be great addition to zun team. On 2016年08月12日 10:26, Yanyan Hu wrote: Both Sudipta and Wenzhi have been actively contributing to the Zun project for a while. Sudipta provided helpful advice for the project roadmap and architecture design. Wenzhi consistently

[openstack-dev] [daisycloud-core] Agenda for IRC meeting Aug. 12 2016

Sorry for publishing agenda so late. 1) Roll Call 2) Daisycloud: Daisy Demo and doc 3) Daisycloud: Ironic status update 4) Daisycloud: Get backend type by calling host_get_all() 5) Daisy4nfv: Related status update B.R., Zhijiang

Re: [openstack-dev] [OpenStack-docs] [neutron] [api] [doc] API reference for neutron stadium projects (re: API status report)

this mail focuses on neutron-specific topics. I dropped cinder and ironic tags. 2016-08-11 23:52 GMT+09:00 Anne Gentle : > > > On Wed, Aug 10, 2016 at 2:49 PM, Anne Gentle > wrote: >> >> Hi all, >> I wanted to report on status and

Re: [openstack-dev] [all] versioning the api-ref?

On 08/12/2016 01:43 PM, Jim Rollenhagen wrote: > On Thu, Aug 11, 2016 at 6:13 PM, John Dickinson wrote: >> >> >> On 11 Aug 2016, at 15:02, Brian Rosmaita wrote: >> >>> I have a question about the api-ref. Right now, for example, the new >>> images v1/v2 api-refs are accurate for

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

Is there some docs for it somewhere? Or some quick way of telling that we've done it and gotten it right? On 12 Aug 2016 08:17, "Andreas Jaeger" wrote: > On 08/12/2016 04:25 AM, Robert Collins wrote: > > On 11 Aug 2016 3:13 PM, "Ben Swartzlander" >

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

On 12 Aug 2016 15:28, "Thierry Carrez" wrote: > > Duncan Thomas wrote: > I agree that leaving broken drivers in tree is not significantly better > from an operational perspective. But I think the best operational > experience would be to have an idea of how much risk you

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

John Dickinson wrote: > [...] > I know the TC has no malicious intent here, and I do support the idea > of having cross-project goals. The first goals proposed seem like > great goals. And I understand the significant challenges of > coordinating goals between a multitude of different projects.

Re: [openstack-dev] Is there a logging_exception_prefix option for Neutron (Juno) ?

Tom Li wrote: Hi, Does anyone know if the Neutron Juno release logging conf allows options such as: logging_exception_prefix, logging_debug_format_suffix, logging_default_format_string, logging_context_format_string like the other general OS services? From the

Re: [openstack-dev] [all] versioning the api-ref?

On Thu, Aug 11, 2016 at 6:13 PM, John Dickinson wrote: > > > On 11 Aug 2016, at 15:02, Brian Rosmaita wrote: > >> I have a question about the api-ref. Right now, for example, the new >> images v1/v2 api-refs are accurate for Mitaka. But DocImpact bugs are >> being generated as we

Re: [openstack-dev] [all] versioning the api-ref?

On 08/11/2016 06:02 PM, Brian Rosmaita wrote: > I have a question about the api-ref. Right now, for example, the new > images v1/v2 api-refs are accurate for Mitaka. But DocImpact bugs are > being generated as we speak for changes in master that won't be > available to consumers until Newton is

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

Jeremy Stanley wrote: On 2016-08-11 20:19:51 +0200 (+0200), Ihar Hrachyshka wrote: Do I read it right that we can now use constraints for post queue too (releasenotes, cover, venv targets)? Yes, that was the hardest part to get working, but thanks to tireless efforts on

Re: [openstack-dev] [TripleO] additional git repo(s) for tripleo-quickstart

On Wed, Aug 10, 2016 at 03:26:18PM -0400, Wesley Hayutin wrote: > Greetings, > > In an effort to make TripleO CI composable and managed and governed by the > TripleO project we have found the need to create additional git repos in > openstack under the TripleO project. This could also be done

[openstack-dev] Barbican: Secure Setup & HSM-plugin

Hi all, As a member of Utimaco's pre-sales team I am currently testing an integration of Barbican with one of our HSMs. We were able to generate MKEKs and HMAC keys on the HSM with the 'pkcs11-key-generation' as well as 'barbican-manage hsm' commands. However, it is not fully clear to us how

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

On 08/12/2016 08:40 AM, Duncan Thomas wrote: > On 12 Aug 2016 15:28, "Thierry Carrez" > wrote: >> >> Duncan Thomas wrote: > >> I agree that leaving broken drivers in tree is not significantly better >> from an operational perspective. But I

[openstack-dev] [charms] out next week/PTL cover

Hi I'm out of contact from everything electronic next week; back on the 22nd August. David Ames (thankyou!) will be covering any Charms PTL related matters in my absence and generally keeping the wheels on development. Cheers James

[openstack-dev] [tempest][plugins] Service clients stable interface in tempest.lib

Hi Tempest plugin developers / maintainers, a new stable interface "ServiceClients" [0][1] is available in Tempest that provides tests with a convenient way to access all available service clients. At the same time the plugin interface is extended with an optional method "get_service_clients"

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

Fantastic news Andreas! -Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [nova] os-capabilities library created

On Thu, Aug 11, 2016 at 9:03 PM, Jay Pipes wrote: > On 08/11/2016 05:46 PM, Clay Gerrard wrote: >> >> On Thu, Aug 11, 2016 at 2:25 PM, Ed Leafe > > wrote: >> >> >> Overall this looks good, although it seems a bit odd to have >>

[openstack-dev] manila service cannot work on liberty

Hi All, Currently, I'm trying to set up manila on an environment which is running Liberty. Both the API and scheduler can operate well, but when I run 'manila service-list', I always get following error: 2016-08-12 17:25:00.470 30562 INFO manila.api.openstack.wsgi [-] OPTIONS

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

On 08/12/2016 12:13 PM, Ihar Hrachyshka wrote: > Jeremy Stanley wrote: > >> On 2016-08-11 20:19:51 +0200 (+0200), Ihar Hrachyshka wrote: >>> Do I read it right that we can now use constraints for post queue too >>> (releasenotes, cover, venv targets)? >> >> Yes, that was the

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

On 08/12/2016 01:44 PM, Ihar Hrachyshka wrote: > Andreas Jaeger wrote: > >> On 08/12/2016 12:13 PM, Ihar Hrachyshka wrote: >>> Jeremy Stanley wrote: >>> On 2016-08-11 20:19:51 +0200 (+0200), Ihar Hrachyshka wrote: > Do I read it right that we can now

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

Duncan Thomas wrote: > Given the options, I'd agree with Sean and John that removing the tag is > a far lesser evil than changing our policy. Agree that the tag should be removed. The Cinder core certainly follows standard deprecation policy, but the Cinder drivers are not. > If we leave broken

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

On 12 Aug 2016, at 13:31, Doug Hellmann wrote: > Excerpts from John Dickinson's message of 2016-08-12 13:02:59 -0700: >> >> On 12 Aug 2016, at 7:28, Doug Hellmann wrote: >> >>> Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: On 10 Aug 2016, at 8:29, Doug Hellmann

Re: [openstack-dev] [OpenStack-docs] [neutron] [api] [doc] API reference for neutron stadium projects (re: API status report)

On Fri, Aug 12, 2016 at 3:29 AM, Akihiro Motoki wrote: > this mail focuses on neutron-specific topics. I dropped cinder and ironic > tags. > > 2016-08-11 23:52 GMT+09:00 Anne Gentle : > > > > > > On Wed, Aug 10, 2016 at 2:49 PM, Anne Gentle < >

[openstack-dev] [Magnum] Using common tooling for API docs

Hi team, As mentioned in the email below, Magnum are not using common tooling for generating API docs, so we are excluded from the common navigation of OpenStack API. I think we need to prioritize the work to fix it. BTW, I notice there is a WIP patch [1] for generating API docs by using

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

Sean Dague wrote: > I 100% understand the cinder policy of kicking drivers out without CI. > And I think there is a lot of value in ensuring what's in tree is tested. > > However, from a user perspective basically it means that if you deploy > Newton cinder and build a storage infrastructure

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

On 12 August 2016 at 16:09, Thierry Carrez wrote: > > How about: 4. Take 3rd-party drivers to a separate cinder-extra-drivers > repository/deliverable under the Cinder team, one that would /not/ have > follows-stable-policy or follows-standard-deprecation tags ? That >

Re: [openstack-dev] [nova] os-capabilities library created

On 08/12/2016 04:05 AM, Daniel P. Berrange wrote: On Wed, Aug 03, 2016 at 07:47:37PM -0400, Jay Pipes wrote: Hi Novas and anyone interested in how to represent capabilities in a consistent fashion. I spent an hour creating a new os-capabilities Python library this evening:

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: > > On 10 Aug 2016, at 8:29, Doug Hellmann wrote: > > > Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400: > >> One of the outcomes of the discussion at the leadership training > >> session earlier this year

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

Duncan Thomas wrote: > [...] > To turn the question around, what is the downside of loosing the tag? The tag does not exist in a vacuum. It describes a behavior that operators want. They want a sane deprecation policy so that the blanket is not pulled from under them without a warning. They want

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

Duncan Thomas wrote: > [...] > Given this need, what are our options? > > 1. We could do all this outside Openstack infrastructure. There are > significant downsides to doing so from organisational, maintenance, cost > etc points of view. Also means that the place vendors go for these > patches

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

Strictly speaking, we only guarantee lvm... If any other driver starts failing CI and nobody steps up to fix it then it wool be removed. I listed ceph and NFS because I think there's enough knowledge and interest in the core team to keep them working without needing any particular company to help

Re: [openstack-dev] [cinder] [nova] locking concern with os-brick

On 8/12/2016 8:24 AM, Sean McGinnis wrote: On Fri, Aug 12, 2016 at 05:55:47AM -0400, Sean Dague wrote: A devstack patch was pushed earlier this cycle around os-brick - https://review.openstack.org/341744 Apparently there are some os-brick operations that are only safe if the nova and cinder

Re: [openstack-dev] [cinder] [nova] locking concern with os-brick

On 8/12/2016 8:52 AM, Matt Riedemann wrote: On 8/12/2016 8:24 AM, Sean McGinnis wrote: On Fri, Aug 12, 2016 at 05:55:47AM -0400, Sean Dague wrote: A devstack patch was pushed earlier this cycle around os-brick - https://review.openstack.org/341744 Apparently there are some os-brick operations

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

On Fri, Aug 12, 2016 at 03:40:47PM +0300, Duncan Thomas wrote: > On 12 Aug 2016 15:28, "Thierry Carrez" wrote: > > > > Duncan Thomas wrote: > > > I agree that leaving broken drivers in tree is not significantly better > > from an operational perspective. But I think the

Re: [openstack-dev] [cinder] [nova] locking concern with os-brick

On Fri, Aug 12, 2016 at 05:55:47AM -0400, Sean Dague wrote: > A devstack patch was pushed earlier this cycle around os-brick - > https://review.openstack.org/341744 > > Apparently there are some os-brick operations that are only safe if the > nova and cinder lock paths are set to be the same

Re: [openstack-dev] [nova] os-capabilities library created

On 08/12/2016 07:49 AM, Jim Rollenhagen wrote: On Thu, Aug 11, 2016 at 9:03 PM, Jay Pipes wrote: On 08/11/2016 05:46 PM, Clay Gerrard wrote: On Thu, Aug 11, 2016 at 2:25 PM, Ed Leafe > wrote: Overall this looks good, although

[openstack-dev] [nova] Fix evaluation of host disk usage by volume-backed instances

Hi Nova developers, This is about the patch: https://review.openstack.org/#/c/200870/19 We would like to fix this issue in Newton and back port it to Mitaka. Reason: Ubuntu 16.04 LTS supports Mitaka release. If we wait for this fix until Ocata release (~April 2017), then Ubuntu team might need

[openstack-dev] [requirements] Why module has been deleted even if it is consumed by the project?

Hi, When I've tried to bump version in ec2api project for some library - I've got an error from requirements-gate job [1]. I've investigated this issue and found that this module was deleted from global requirements with comment 'only ec2api is using it'. It was done in the review [2]. What

Re: [openstack-dev] [nova] Fix evaluation of host disk usage by volume-backed instances

Hi Abhishek There were a number of tries to analyze if an instance is booted from volume in DiskFilter itself. All reviews were stopped by core team members. As for you assume about image_ref is None for such instances, it is not right for an instance booted from a volume backed image (a

Re: [openstack-dev] [requirements] Why module has been deleted even if it is consumed by the project?

On 08/12/2016 09:53 AM, Andrey Pavlov wrote: > Thanks for the answer, > > I don't know why - but requirements job is not in the list of jobs. It > present only in comment from jenkins. > Logs are here > - > http://logs.openstack.org/67/354667/1/check/gate-ec2-api-requirements/4e9e1da/ > > And I

[openstack-dev] [nova] Thoughts on testing novaclient functional with neutron

I opened a bug yesterday against novaclient for running the functional tests against a neutron-backed devstack: https://bugs.launchpad.net/python-novaclient/+bug/1612410 With neutron being the default in devstack now, people hacking on novaclient and running functional tests locally are going

[openstack-dev] [cinder] [nova] locking concern with os-brick

A devstack patch was pushed earlier this cycle around os-brick - https://review.openstack.org/341744 Apparently there are some os-brick operations that are only safe if the nova and cinder lock paths are set to be the same thing. Though that hasn't yet hit release notes or other documentation yet

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

Andreas Jaeger wrote: On 08/12/2016 12:13 PM, Ihar Hrachyshka wrote: Jeremy Stanley wrote: On 2016-08-11 20:19:51 +0200 (+0200), Ihar Hrachyshka wrote: Do I read it right that we can now use constraints for post queue too (releasenotes, cover, venv

Re: [openstack-dev] [requirements] Why module has been deleted even if it is consumed by the project?

Excerpts from Andrey Pavlov's message of 2016-08-12 16:50:21 +0300: > Hi, > > When I've tried to bump version in ec2api project for some library - I've > got an error from requirements-gate job [1]. > I've investigated this issue and found that this module was deleted from > global requirements

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

On 16-08-12 09:21 AM, Thierry Carrez wrote: Sean Dague wrote: I 100% understand the cinder policy of kicking drivers out without CI. And I think there is a lot of value in ensuring what's in tree is tested. However, from a user perspective basically it means that if you deploy Newton cinder

Re: [openstack-dev] [release] Branching Gnocchi stable/2.2

Excerpts from Julien Danjou's message of 2016-08-12 09:10:34 +0200: > Hi release team, > > I've asked on IRC, but I guess it's safer on the ml. > > We tagged Gnocchi 2.2.0 using the release repo, but as discussed earlier > on this list, the branching system is not ready yet. So we'd need >

Re: [openstack-dev] [OpenStack-docs] [neutron] [api] [doc] API reference for neutron stadium projects (re: API status report)

Akihiro Motoki wrote: > this mail focuses on neutron-specific topics. I dropped cinder and ironic > tags. > > 2016-08-11 23:52 GMT+09:00 Anne Gentle : >> >> >> On Wed, Aug 10, 2016 at 2:49 PM, Anne Gentle >>

Re: [openstack-dev] [requirements] Why module has been deleted even if it is consumed by the project?

Thanks for the answer, I don't know why - but requirements job is not in the list of jobs. It present only in comment from jenkins. Logs are here - http://logs.openstack.org/67/354667/1/check/gate-ec2-api-requirements/4e9e1da/ And I would like to include ec2api project to openstack/requirements/

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

On Fri, Aug 12, 2016 at 7:37 AM, Sean McGinnis wrote: > On Fri, Aug 12, 2016 at 03:40:47PM +0300, Duncan Thomas wrote: > > On 12 Aug 2016 15:28, "Thierry Carrez" wrote: > > > > > > Duncan Thomas wrote: > > > > > I agree that leaving broken drivers

Re: [openstack-dev] [openstack-ansible][security] Adding RHEL 7 STIG to openstack-ansible-security

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/04/2016 12:45 PM, Major Hayden wrote: > The existing openstack-ansible-security role uses security configurations > from the Security Technical Implementation Guide (STIG) and the new Red Hat > Enterprise Linux 7 STIG is due out soon. The

Re: [openstack-dev] [release] Branching Gnocchi stable/2.2

On Fri, Aug 12 2016, Doug Hellmann wrote: > I've created the branch, which includes a patch to update the .gitreview > file [1] and another to update the release notes [2]. You may want to > modify that release note patch, so feel free to take it over and fix it > up how you like. Perfect,

[openstack-dev] [nova][scheduler] Next Scheduler Subteam meeting

The next meeting of the Nova Scheduler subteam will be on Monday, August 15 at 1400 UTC in #openstack-meeting-alt http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160815T14 The agenda is here: https://wiki.openstack.org/wiki/Meetings/NovaScheduler If you have any items you wish

[openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

TL;DR: Projects can use bindep.txt to document in a programmatic way their binary dependencies Python developers record their dependencies on other Python packages in requirements.txt and test-requirements.txt. But some packages havedependencies outside of python and we should document

Re: [openstack-dev] [nova] Thoughts on testing novaclient functional with neutron

On 12 August 2016 at 08:13, Matt Riedemann wrote: > I opened a bug yesterday against novaclient for running the functional > tests against a neutron-backed devstack: > > https://bugs.launchpad.net/python-novaclient/+bug/1612410 > > With neutron being the default in

Re: [openstack-dev] Barbican: Secure Setup & HSM-plugin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Manuel, I'm happy to hear about your interest in Barbican. I assume your HSM has a PKCS#11 interface since the admin commands to generate the MKEK and HMAC keys worked for you. The labels for the generated keys should be specified in the

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja wrote: > > Lets say I was ops evaluating different options as storage vendor for > my cloud and I get told that "Here is the list of supported drivers > for different OpenStack Cinder back ends delivered by Cinder team", I > start

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

On Fri, Aug 12, 2016 at 12:10 PM, Walter A. Boring IV wrote: > > I was leaning towards a separate repo until I started thinking about all > the overhead and complications this would cause. It's another repo for > cores to watch. It would cause everyone extra complication

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

I was leaning towards a separate repo until I started thinking about all the overhead and complications this would cause. It's another repo for cores to watch. It would cause everyone extra complication in setting up their CI, which is already one of the biggest roadblocks. It would make it a

[openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

The use_untested_probably_broken_deprecated_manger_so_maybe_i_can_migrate_cross_fingers option sounds good! The experiment would be then if it's still enough of a stick to keep 3rd party drivers pony'd up on their commitment to the Cinder team to consistently ship quality releases? What about

Re: [openstack-dev] [nova] Thoughts on testing novaclient functional with neutron

On Fri, Aug 12, 2016 at 10:13 AM, Matt Riedemann wrote: > Another idea is the base functional test that sets up the client just > checks the keystone service catalog for a 'network' service entry, > somewhere in here: > This is exactly the route OSC takes for those

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

bindep is great, and we've been using it in Swift for a while now. I'd definitely recommend it to other projects. Andreas, I didn't see a patch proposed to Swift to move the file. I don't want to get in the way of your tool, though. Is there a patch that will be proposed, or should I do that

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

I'd noticed other-requirements.txt around, but figured it needed a bunch of custom tooling to actually make it useful. And... it's a subprocess wrapper to a handful of package management tools (surprised to see emerge and pacmac - Kudos!) and a custom format for describing package requirements...

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

Excerpts from John Dickinson's message of 2016-08-12 13:02:59 -0700: > > On 12 Aug 2016, at 7:28, Doug Hellmann wrote: > > > Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: > >> > >> On 10 Aug 2016, at 8:29, Doug Hellmann wrote: > >> > >>> Excerpts from Doug Hellmann's

[openstack-dev] [neutron] OVO Status Dashboard

Hey neutrinos, First of all, the high priority for OVO implementation in newton release are the implementation and integration of port, subnet and network objects, but given that more people is joining to this initiative and also many patches are related directly and indirectly to this, results

Re: [openstack-dev] [nova] Fix evaluation of host disk usage by volume-backed instances

I am working on a POC with this approach and will test all possible scenarios (boot, resize, reboot, compute service stop/start, shelved-unshelved etc). Please let me know your opinion about the same or you have any other solution in mind. Hi Abhishek, FWIW, I'm working on a patch to

Re: [openstack-dev] [nova] os-capabilities library created

> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Friday, August 12, 2016 2:20 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova] os-capabilities library created > > On 08/12/2016 04:05 AM, Daniel P. Berrange wrote: > > On Wed, Aug

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

On 2016-08-12 21:20:34 +0200 (+0200), Julien Danjou wrote: [...] > If bindep.txt is present, are the "standard" packages still installed? > If yes, this is going to be more challenging to get bindep.txt right, as > a missing entry will go unnoticed. As Andreas mentioned, we have a fallback

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

On 12 Aug 2016, at 7:28, Doug Hellmann wrote: > Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700: >> >> On 10 Aug 2016, at 8:29, Doug Hellmann wrote: >> >>> Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400: One of the outcomes of the discussion at the

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

On 08/12/2016 01:10 PM, Walter A. Boring IV wrote: > >> I was leaning towards a separate repo until I started thinking about all >> the overhead and complications this would cause. It's another repo for >> cores to watch. It would cause everyone extra complication in setting up >> their CI, which

Re: [openstack-dev] [requirements] Why module has been deleted even if it is consumed by the project?

ec2-api (and gce-api) already has this job, so I just add them to projects.txt, right? https://review.openstack.org/#/c/354899/ and after this will be merged I can revert botocore requirement to global-requirements, right? On Fri, Aug 12, 2016 at 6:21 PM, Matthew Thode

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

On 08/12/2016 08:37 PM, Clay Gerrard wrote: > I'd noticed other-requirements.txt around, but figured it needed a bunch > of custom tooling to actually make it useful. > > And... it's a subprocess wrapper to a handful of package management > tools (surprised to see emerge and pacmac - Kudos!) and

Re: [openstack-dev] [requirements] Why module has been deleted even if it is consumed by the project?

On 08/12/2016 01:47 PM, Andrey Pavlov wrote: > ec2-api (and gce-api) already has this job, so I just add them to > projects.txt, right? > > https://review.openstack.org/#/c/354899/ yep, looks good, +2 -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

On Fri, Aug 12, 2016 at 11:52 AM, Andreas Jaeger wrote: > > On 08/12/2016 08:37 PM, Clay Gerrard wrote: > > > > ... but ... it doesn't have a --install option? Do you know if that is > > strictly out-of-scope or roadmap or ... ? > > > Right now we don't need it - we take the

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

Excerpts from Sean Dague's message of 2016-08-12 14:43:57 -0400: > On 08/12/2016 01:10 PM, Walter A. Boring IV wrote: > > > >> I was leaning towards a separate repo until I started thinking about all > >> the overhead and complications this would cause. It's another repo for > >> cores to watch.

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

On 08/12/2016 09:20 PM, Julien Danjou wrote: > On Fri, Aug 12 2016, Andreas Jaeger wrote: > >> Projects are encouraged to create their own bindep files. Besides >> documenting what is required, it also gives a speedup in running tests >> since you install only what you need and not all packages

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

On 08/12/2016 08:07 PM, John Dickinson wrote: > bindep is great, and we've been using it in Swift for a while now. I'd > definitely recommend it to other projects. > > Andreas, I didn't see a patch proposed to Swift to move the file. I don't > want to get in the way of your tool, though. Is

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

On Fri, Aug 12 2016, Andreas Jaeger wrote: > Projects are encouraged to create their own bindep files. Besides > documenting what is required, it also gives a speedup in running tests > since you install only what you need and not all packages that some > other project might need and are

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

On 12 August 2016 at 12:09, Clay Gerrard wrote: > > > On Fri, Aug 12, 2016 at 11:52 AM, Andreas Jaeger wrote: >> >> On 08/12/2016 08:37 PM, Clay Gerrard wrote: >> > >> > ... but ... it doesn't have a --install option? Do you know if that is >> > strictly