Re: [openstack-dev] [Fuel][CI] CI on commit message

Hi, I think that checking commit message compliance to commit message guidelines (for example ending the first line with dot) is part of CI jobs, and they will vote -1 if message is wrongly structured. Maybe there should be separate CI job only for checking commit message? Cheers, Maciej Kwiek

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Hi, How do I sign in to this? I am asked for credentials. -Sam. From: Jain, Vivek [mailto:[email protected]] Sent: Wednesday, July 29, 2015 5:54 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

On Wed, Jul 29, 2015 at 7:08 AM, Mike Scherbakov wrote: > Looks like Fuel Menu can't solve this one. Is there workaround possible > (even with worse UX)? add to fuel-menu ability to load yaml file with network scheme. However, I can't predict how serial console can live with zmodem (or somethin

Re: [openstack-dev] [Fuel][CI] CI on commit message

-1 to Maciej +1 to Sergii /sv __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/ope

Re: [openstack-dev] [designate] The designate API service is stopped

Hi Kiall, We haven't found the cause yet. Even moving the host to the same network, the error still happens :( We decided to migrate to rabbitmq. While migrating OST to rabbitmq, I've connected to the local rabbitmq, and I've also seen the same problem (all designate processes and rabbitmq in the

Re: [openstack-dev] [Ironic] Let's talk about API versions

On 07/28/2015 10:51 PM, Devananda van der Veen wrote: On Tue, Jul 28, 2015 at 1:01 AM Dmitry Tantsur mailto:[email protected]>> wrote: On 07/27/2015 10:41 PM, Sean Dague wrote: > On 07/27/2015 04:35 PM, Jim Rollenhagen wrote: >> Hi friends. >> >> Ironic implemented API

Re: [openstack-dev] [infra][puppet] Keeping common set of file synchronized across puppet modules

On 07/28/2015 07:13 PM, Andreas Jaeger wrote: > On 07/28/2015 03:35 PM, Yanis Guenane wrote: >> In PuppetOpenstack we have a common set of filesthat are shared across >> all our modules. >> We would like to have an easy way to keep those set of >> filessynchronized. >> Based on some discussions o

Re: [openstack-dev] [Fuel][CI] CI on commit message

Hi, > I think that checking commit message compliance to commit message guidelines (for example ending the first line with dot) is part of CI jobs, and they will vote -1 if message is wrongly structured. Maciej, we don't have such checks at the moment. You can craft any commit message you want a

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

Hi, On Wed, Jul 29, 2015 at 10:19 AM, Sergey Vasilenko wrote: > add to fuel-menu ability to load yaml file with network scheme. > However, I can't predict how serial console can live with zmodem (or > something else serial communication protocol) on the same serial port. > Why should we overcom

Re: [openstack-dev] [Ironic] Let's talk about API versions

>> 1. yes >> 2. no -- the client should default to the minimum supported version. We got >> that wrong previously, and that's what is hurting us now. > > So if we do this, simply shipping the code doesn't break anyone. Nobody > has disagreed on this yet, best I can tell. > We would still need a de

Re: [openstack-dev] [Fuel][CI] CI on commit message

I agree with Maciej 1. Simple change in CommitMessage shouldn't spin up CI check 2. There should be simple task where we check "Implements: blueprint" or "Closes-Bug:" or Related-Bug:" to set -1 automatically 3. There can be additional checks like Short Summary should be 50 or less symbols. Long s

Re: [openstack-dev] [Fuel][CI] CI on commit message

Guys, How do you suppose to know that only commit message was changed? Do you want to implement manual comparison between patch sets?! Currently Gerrit checks whether patchset was changed or not by tracking Git commit SHA1 sum, and, btw, chaning commit message will lead to changing commit sha1 su

[openstack-dev] [all][infra] CI System is broken

Currently Zuul is stuck and not processing any events at all, thus no jobs are checked or gated. There'S no need to recheck any changes right now, please have patience until the infra team has isolated and fixed the problem. We'll send a clear message once everything is fine again, Andreas -

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

On Tue, Jul 28, 2015 at 09:48:25AM -0400, Doug Hellmann wrote: > Excerpts from Gorka Eguileor's message of 2015-07-28 10:37:42 +0200: > > On Fri, Jul 24, 2015 at 10:08:45AM -0400, Doug Hellmann wrote: > > > Excerpts from Kekane, Abhishek's message of 2015-07-24 06:33:00 +: > > > > Hi Devs, > >

Re: [openstack-dev] [Fuel][CI] CI on commit message

@Aleksandr: it seems you are right, after my first broken commit message I was careful not to mess them up again and I didn't even notice that this check was turned off. Just curious: why was it turned off? On Wed, Jul 29, 2015 at 11:24 AM, Igor Kalnitsky wrote: > Guys, > > How do you suppose to

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

Interested in, have the time been determined? /Yalei From: Antoni Segura Puimedon [mailto:[email protected]] Sent: Friday, July 24, 2015 3:30 AM To: Stephen Wong Cc: Eran Gampel; OpenStack Development Mailing List (not for usage questions); Irena Berezovsky Subject: Re: [openstack-de

[openstack-dev] [puppet] puppet-keystone to setup SELinux booleans if running in httpd

Hi, I have review [1] where I turn on SELinux booleans if we are running keystone in httpd. I'm for doing this in puppet as package should not set configuration especially system wide one, where we allow httpd to access databases and to bind to keystone ports. I'd like to hear your opinions on

[openstack-dev] [Tricircle]Team Weekly Meeting 2015.07.29

Hi Team， We will as usual have our meeting starting from UTC1300 today. The main topic would be the design BP and DAL patch opened by Zhiyuan. -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Prooduct Line Huawei Technologies Co,. Ltd Email: [email protected] Office: Hu

Re: [openstack-dev] [murano] eslint cleanup

I gave it some thought, and came to a conclusion, that adopting openstack config is the right thing to do. It enables some of the rules, that are disabled by default, so it actually is stricter, than our current config. So  https://review.openstack.org/#/c/206729/ Thank you again for your work M

Re: [openstack-dev] [nova] Exposing provider networks in network_data.json

On Mon, Jul 20, 2015 at 10:19:02AM EDT, Jim Rollenhagen wrote: > On Mon, Jul 20, 2015 at 12:56:10PM +, Sean M. Collins wrote: > > On Sun, Jul 19, 2015 at 02:26:32PM EDT, Jim Rollenhagen wrote: > > > For a little background, this patch came from code that is running in > > > production today, wh

Re: [openstack-dev] [Fuel][Plugins] Feedback

Hey Sergii – I don’t know if I agree with the statement that it’s bad practice to mix core and plugin functionality. From a user standpoint, if I’m trying to deploy something like Contrail, I would like to see all of my Networking configuration options together (including the Contrail plugin) s

Re: [openstack-dev] [infra][puppet] Keeping common set of file synchronized across puppet modules

On 2015-07-29 10:53:38 +0200 (+0200), Yanis Guenane wrote: > On 07/28/2015 07:13 PM, Andreas Jaeger wrote: [...] > > * If there is a proposed change already for a project, reuse that one > > instead of creating a new one? > > I don't have the answer for that I'd have to look. But this should never

[openstack-dev] [Nova][Neutron] Using Barbican to share metadata_proxy_shared_secret ?

I recently nitpicked the following DevStack review https://review.openstack.org/#/c/205901/3/lib/neutron-legacy,cm Since this setting is shared between Neutron and Nova, and currently it requires an operator to populate two config files, it sounds like a good candidate for using Barbican to store

Re: [openstack-dev] [Fuel][Plugins] Feedback

On 29 Jul 2015 at 14:41:48, Sheena Gregson ([email protected]) wrote: Hey Sergii –   I don’t know if I agree with the statement that it’s bad practice to mix core and plugin functionality.  From a user standpoint, if I’m trying to deploy something like Contrail, I would like to see all of m

Re: [openstack-dev] [Ironic] Let's talk about API versions

After reading through this thread as a whole, I¹d like to summarise my thoughts so far: * I've noticed all these discussions revolve around existing people using the API, and seem to ignore that most new users of the API don¹t care how it used to work, and just want the full feature set without h

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

On 2015-07-28 19:25:04 -0700 (-0700), Clay Gerrard wrote: [...] > I'd be more curious for the documentation if you have any idea where I > might look for it? Is this a feature of pkg_resources, distutils, > setuptools, pbr? What exactly does describing dependencies via this > "extras" key afford?

Re: [openstack-dev] [Fuel][Plugins] Feedback

It’s also worth mentioning that there has been discussion about transitioning current “core” components of Fuel to plugins (like Ceph or the current vCenter implementation). In these cases, as with others, displaying the plugin’s functionality in its logical location from a user perspective will

Re: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup?

On 24 July 2015 at 22:49, Jay S. Bryant wrote: > All, > > I had the opportunity to chat with John Garbutt when he was here in > Rochester for the Nova mid-cycle meet-up. We discussed the fact that there > was much to be gained by improving the communication between the Cinder and > Nova teams. W

Re: [openstack-dev] [Nova] Cancel Nova API meeting this week

Sorry I forgot to send that to the ML myself, thanks for sending that out. The cancellation was 'announced' just after the last meeting, in the usual wiki page: https://wiki.openstack.org/wiki/Meetings/Nova Please note the time for this week keeps on the same rotation, so its: July 30th 2015 2100

[openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

stable/kilo and grenade (master) jobs are going to be blocked for some projects until the kilo 2015.1.2 version changes are merged: https://review.openstack.org/#/q/I180de9d4f1f4ae385682ce40a3a695eb3acc4c43,n,z So avoid rechecks for grenade failures until these are merged (at least nova and ir

Re: [openstack-dev] [all][infra] CI System is broken

On 2015-07-29 11:33, Andreas Jaeger wrote: Currently Zuul is stuck and not processing any events at all, thus no jobs are checked or gated. There'S no need to recheck any changes right now, please have patience until the infra team has isolated and fixed the problem. We'll send a clear message o

Re: [openstack-dev] [all][infra] CI System is broken

On 2015-07-29 15:16, Andreas Jaeger wrote: On 2015-07-29 11:33, Andreas Jaeger wrote: Currently Zuul is stuck and not processing any events at all, thus no jobs are checked or gated. There'S no need to recheck any changes right now, please have patience until the infra team has isolated and fix

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 7/29/2015 8:17 AM, Matt Riedemann wrote: stable/kilo and grenade (master) jobs are going to be blocked for some projects until the kilo 2015.1.2 version changes are merged: https://review.openstack.org/#/q/I180de9d4f1f4ae385682ce40a3a695eb3acc4c43,n,z So avoid rechecks for grenade failure

[openstack-dev] [Horizon][Trove] About Trove policies

Hi all, I'm currently working on two blueprints to improve the Trove support in Horizon: 1. blueprint trove-list-datastores-and-versions 2. blueprint datatable-column-level-policy-checks <-- needed by the first When requesting Trove API to get datastore versions, the response contains more data

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 07/29/2015 09:29 AM, Matt Riedemann wrote: > > > On 7/29/2015 8:17 AM, Matt Riedemann wrote: >> stable/kilo and grenade (master) jobs are going to be blocked for some >> projects until the kilo 2015.1.2 version changes are merged: >> >> https://review.openstack.org/#/q/I180de9d4f1f4ae385682ce4

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote: > On 07/29/2015 09:29 AM, Matt Riedemann wrote: > > On 7/29/2015 8:17 AM, Matt Riedemann wrote: [...] > > > ValueError: git history requires a target version of > > > pbr.version.SemanticVersion(2015.1.2), but target version is > > > pbr.versi

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 7/29/2015 8:39 AM, Sean Dague wrote: On 07/29/2015 09:29 AM, Matt Riedemann wrote: On 7/29/2015 8:17 AM, Matt Riedemann wrote: stable/kilo and grenade (master) jobs are going to be blocked for some projects until the kilo 2015.1.2 version changes are merged: https://review.openstack.org

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 07/29/2015 09:49 AM, Jeremy Stanley wrote: > On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote: >> On 07/29/2015 09:29 AM, Matt Riedemann wrote: >>> On 7/29/2015 8:17 AM, Matt Riedemann wrote: > [...] ValueError: git history requires a target version of pbr.version.SemanticVersion

[openstack-dev] OpenStack Speaker Support

Does anyone monitor [email protected] ? I’ve been waiting for a reply for a few days now. Thanks, - Doug Mendizábal signature.asc Description: Message signed with OpenPGP using GPGMail

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

On Wed, Jul 29, 2015 at 12:01 PM, Sergii Golovatiuk < [email protected]> wrote: > > add to fuel-menu ability to load yaml file with network scheme. >> However, I can't predict how serial console can live with zmodem (or >> something else serial communication protocol) on the same serial por

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

On Tue, Jul 28, 2015 at 07:55:54PM -0400, Doug Hellmann wrote: > I replied on both patches, but I'll repeat it here for a broader > audience: > > Please set up an "extras" entry for each backend instead of just > removing the dependencies. That will signal to users that you know > what dependenci

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

Excerpts from Sean Dague's message of 2015-07-29 09:54:08 -0400: > On 07/29/2015 09:49 AM, Jeremy Stanley wrote: > > On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote: > >> On 07/29/2015 09:29 AM, Matt Riedemann wrote: > >>> On 7/29/2015 8:17 AM, Matt Riedemann wrote: > > [...] > ValueErr

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 2015-07-29 10:32:09 -0400 (-0400), Doug Hellmann wrote: > Another solution is to move all projects to post-versioning and > stop setting a version in setup.cfg. That would mean having all > projects following the release:cycle-with-intermediary model, and > I intend to propose making that change

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 7/29/2015 9:32 AM, Doug Hellmann wrote: Excerpts from Sean Dague's message of 2015-07-29 09:54:08 -0400: On 07/29/2015 09:49 AM, Jeremy Stanley wrote: On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote: On 07/29/2015 09:29 AM, Matt Riedemann wrote: On 7/29/2015 8:17 AM, Matt Riedeman

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

Excerpts from Clay Gerrard's message of 2015-07-28 19:25:04 -0700: > Doug, > > I believe our glance friends are not the only project with some open > questions on dealing with the "required dependency for optional plugin" > use-case. You've made a recommendation to leverage some python tooling >

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

Excerpts from Louis Taylor's message of 2015-07-29 15:25:33 +0100: > On Tue, Jul 28, 2015 at 07:55:54PM -0400, Doug Hellmann wrote: > > I replied on both patches, but I'll repeat it here for a broader > > audience: > > > > Please set up an "extras" entry for each backend instead of just > > removi

[openstack-dev] [nova] Bug Triage Day - Liberty

I'd like to spread the idea of doing a "bug triage day" on nextWednesday, August 5th.   This is one of our special review days [1] and sets the ground for thefollowing timeframe where we focus on fixing bugs. Would be great if youcould shift your focus on this day to triaging [2] to* review critica

[openstack-dev] [nova] StorPool attachment driver approval? [Was: Reminder: July 16 is non-priority feature proposal freeze]

On Tue, Jul 14, 2015 at 09:56:56PM +0100, John Garbutt wrote: > On 14 July 2015 at 18:40, Ed Leafe wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On 07/14/2015 05:52 AM, John Garbutt wrote: > > > >> Please note, the non-priority feature freeze is on: July 30 > > So technic

Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

Would send ceph estimation tomorrow. Yet estimation != ETTA On Wed, Jul 29, 2015 at 12:27 AM, Sergii Golovatiuk wrote: > Hi, > > Let's ask our Ceph developers how much time/resources they need to implement > such functionality. > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

Hi Yalei, We set a date/time, its going to be Monday at 15:00 UTC If you can't attend, i will be happy to update you on IRC when i am around, and you can also approach Antoni (apuimedo in IRC) if you have any questions. Hope to see you involved! Gal. On Wed, Jul 29, 2015 at 12:53 PM, Wang, Yal

[openstack-dev] [os-ansible-deployment][openstack-ansible] Ceph / OpenStack Integration

Hi All, We've got an open blueprint [1] on the os-ansible-deployment project to add the ability to configure Cinder / Glance / Nova to use an existing Ceph storage backend. The implementation [2] is in flight and has seen some thorough reviews already, but we welcome anyone with Ceph / OpenStack

[openstack-dev] [tc][kolla] Application for big tent

TCers, The Kolla development community jointly produced our commit message and commit contents via Etherpad at the first day of our Midcycle this week during a 1 hour live editing session. The Kolla project humbly requests application to the big tent. [1] Thanks! -steve [1] https://review.op

Re: [openstack-dev] [nova] Bug Triage Day - Liberty

On 07/29/2015 08:13 AM, Markus Zoeller wrote: I'd like to spread the idea of doing a "bug triage day" on next Wednesday, August 5th. This is one of our special review days [1] and sets the ground for the following timeframe where we focus on fixing bugs. Would be great if you could shift your fo

[openstack-dev] [infra] Getting notified of closed pull requests on github?

Every now and then I go look at github to see what pull requests have been auto-closed there, since it seems most of the repos under https://github.com/openstack/(.*) auto-close pull requests (with messages telling people to use gerrit); I'm wondering though if there is anyway to notify the ma

Re: [openstack-dev] [horizon] [stable] Freeze exception

> I would like to request for a freeze exception for the this bug: > https://bugs.launchpad.net/horizon/+bug/1474618 > > This is the patch: > https://review.openstack.org/#/c/206184/ Too late for 2015.1.1, tags (except neutron) have been pushed but certainly fine to merge to stable/kilo. Cheers,

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

You have to request access from Piet (copied here) or reach out to folks in the #openstack-ux room. -Lin On Wed, Jul 29, 2015 at 12:22 AM, Samuel Bercovici wrote: > Hi, > > How do I sign in to this? > > I am asked for credentials. > > -Sam. > > > > > > *From:* Jain, Vivek [mailto:vivekj...@eb

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 30 July 2015 at 01:39, Sean Dague wrote: > So, after every release a giant amount of patches all have to land lock > step or everything is broken? No, its not that bad. The *tagged* commit is fine forever. The *first* commit in each branch has to be the identification of the new version in

[openstack-dev] Virtual Box Vagrant

Hi , I am new to OpenStack , I am trying to get the Latest version of OpenStack , on a VM with VirtualBox on a MAC. Can somebody point me to a wiki page or a repo, which would have the stuff for me , so that I can get it up and running. I need the horizon dashboard working for my related work

Re: [openstack-dev] [nova] Bug Triage Day - Liberty

On 29 July 2015 at 17:13, Jay Pipes wrote: > On 07/29/2015 08:13 AM, Markus Zoeller wrote: >> >> I'd like to spread the idea of doing a "bug triage day" on next >> Wednesday, August 5th. >> >> This is one of our special review days [1] and sets the ground for the >> following timeframe where we fo

[openstack-dev] [packaging][all] setting minimum version of setuptools in setup.py

Similar to pbr, we have a minimum version of setuptools required to consistently install things in OpenStack. Right now thats 17.1. However, we don't declare a setup_requires version for it. I think we should. setuptools can't self-upgrade, and we don't have declarative deps yet, so one reaction

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 07/29/2015 01:21 PM, Robert Collins wrote: > On 30 July 2015 at 01:39, Sean Dague wrote: > >> So, after every release a giant amount of patches all have to land lock >> step or everything is broken? > > No, its not that bad. > > The *tagged* commit is fine forever. > > The *first* commit in

[openstack-dev] [Fuel] Restrictions in Fuel API: nova-network

Folks, why do we even want to introduce restrictions? Please see https://bugs.launchpad.net/fuel/+bug/1470488 about locking nova-network. We already suffer from locked Settings tab in our API. Instead, we just need to introduce a warning, that this option is deprecated and it's on risk of a user

Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network

We restricted this because allowing nova-network to be used as an underlay for all possible combinations added QA time and effort to supporting a soon to be deprecated option. As nova-network is being deprecated upstream and will relatedly be deprecated in Fuel – AFAIK, there is a goal to deprec

Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network

I'm fine with removing the related code from Fuel then, but I'm not Ok with introducing limitations code. If we don't want to remove the code (and I believe we don't because of backward compatibility reasons), then why don't we just add a warning that this is deprecated / unsopported? And QA will

[openstack-dev] [nova] Thoughts on things that don't make freeze cutoffs

We talked a bit about this at the nova mid-cycle last week but I can't say I completely remember all of the points made, since I feel like we talked ourselves into a circle that got us back to more or less 'the current specs and freeze process is the least of all evils so let's not change it'.

Re: [openstack-dev] [nova] StorPool attachment driver approval? [Was: Reminder: July 16 is non-priority feature proposal freeze]

On 7/29/2015 10:16 AM, Peter Penchev wrote: On Tue, Jul 14, 2015 at 09:56:56PM +0100, John Garbutt wrote: On 14 July 2015 at 18:40, Ed Leafe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/14/2015 05:52 AM, John Garbutt wrote: Please note, the non-priority feature freeze is o

Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network

I think it becomes challenging to communicate to users why some of the nova-network flows show a warning and are not tested while others appear to work without issue. For example, a customer using multi-HV would see a successful nova-network selection, but if they change to using only KVM/QEMU,

[openstack-dev] [neutron][lbaas] Tempest apiv2 tests are erroring out.

Following tempest apiv2 tests are failing at CI setup (with NetScaler Backend) and resulting into negative vote for all changes. --- neutron_lbaas.tests.tempest.v2.api.test_listeners_ad

[openstack-dev] [Nova] Non-priority Feature Freeze is Tomorrow (July 30th)

Hi, Tomorrow is: Non-priority Feature Freeze What does this mean? Well... * bug fixes: no impact, still free to merge * priority features: no impact, still free to merge * clean ups: sure we could merge those * non-priority features (i.e. blueprints with a low priority), you are no longer free t

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

> From: Doug Hellmann > To: openstack-dev > Date: 07/28/2015 07:59 PM > Subject: Re: [openstack-dev] [glance] Removing python-swiftclient > from requirements.txt > > I replied on both patches, but I'll repeat it here for a broader > audience: > > Please set up an "extras" entry for each backe

Re: [openstack-dev] Virtual Box Vagrant

Lots and lots of choices out there :) Github.com/stackforge/os-ansible-deployment <-- this is a COMPLETE solution using Docker. It is a good example of what is needed for a real deployment. Github.com/lorin/devstack-vm <<- just a simple devstack running in Vagrant. You could add here as needed

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

So helpful! Thank you. On Wed, Jul 29, 2015 at 7:48 AM, Doug Hellmann wrote: > > There is some documentation in the pbr manual > (http://docs.openstack.org/developer/pbr/#extra-requirements). The > feature is implemented throughout the packaging tool chain now. > > Ah, excellent! PEP 0426 see

Re: [openstack-dev] [keystone] the status of ec2 api

On Mon, Jul 13, 2015 at 9:50 PM, Ken'ichi Ohmichi wrote: > Hi Keystone team, > > Now the test of ec2 credentials[1] is been proposed to Tempest, and > I'd like to know current situation of ec2 api on Keystone as a Tempest > reviewer. > > On Nova instead, ec2 api is deprecated in Nova and the stan

Re: [openstack-dev] [keystone] the status of ec2 api

On Wed, Jul 29, 2015 at 1:49 PM, Brant Knudson wrote: > > > On Mon, Jul 13, 2015 at 9:50 PM, Ken'ichi Ohmichi > wrote: > >> Hi Keystone team, >> >> Now the test of ec2 credentials[1] is been proposed to Tempest, and >> I'd like to know current situation of ec2 api on Keystone as a Tempest >> rev

[openstack-dev] Make libguestfs available on pypi

We are packaging nova in a venv so that we can run some kilo code on top of some cent6 nodes (default python install is 2.6) (additionally we are working on replacing the cent6 nodes with a newer os, but when you have a large number of machines - things take time). We are using python27 softwar

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Ah. I see. Thanks. Kevin From: Jain, Vivek [[email protected]] Sent: Tuesday, July 28, 2015 8:00 PM To: OpenStack Development Mailing List (not for usage questions); Fox, Kevin M Cc: Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for ne

[openstack-dev] [fuel][puppet] Fuel Library and upstream modules

Hello everyone, I have put together a wiki describing the proposed interactions between fuel-library and upstream modules based on previous talks around librarian-puppet[0]. Please take some time to review https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules. This page provides a br

Re: [openstack-dev] [openstack-infra][Infra][Neutron] Nominating intel-networking-ci for voting rights

I've put a patch up [1] to indicate we don't want thirdparty CI systems voting. If everyone agrees that's fine, we'll merge the patch and revert the voting rights of the 3rd party CI systems. If people are not in favor of this, please vote accordingly on the patch itself. We'll review at next week'

Re: [openstack-dev] [magnum][blueprint] magnum-service-list

Hi Jay, 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the abstraction was inspired from the same in kubernetes, but the data stored in DB about a 'service' is properly abstracted and not k8s-specific at the top level. If we plan to change this to 'k8s-service-list', t

[openstack-dev] [kolla] Mission change suggested by the TC for big tent

Doug Hellman of the TC suggested we change the mission statement of Kolla to be a little less specific. The new mission statement I submitted in the review is here Is basically cutting off the last part of the mission statement sentence: https://review.openstack.org/#/c/206789/ If your a Kolla

Re: [openstack-dev] [kolla] Mission change suggested by the TC for big tent

Excerpts from Steven Dake (stdake)'s message of 2015-07-29 20:07:26 +: > Doug Hellman of the TC suggested we change the mission statement of Kolla to > be a little less specific. The new mission statement I submitted in the > review is here Is basically cutting off the last part of the missi

Re: [openstack-dev] [openstack-infra][Infra][Neutron] Nominating intel-networking-ci for voting rights

On 2015-07-29 15:00:40 -0500 (-0500), Kyle Mestery wrote: > I've put a patch up [1] to indicate we don't want thirdparty CI > systems voting. If everyone agrees that's fine, we'll merge the > patch and revert the voting rights of the 3rd party CI systems. If > people are not in favor of this, pleas

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 7/29/2015 12:45 PM, Sean Dague wrote: On 07/29/2015 01:21 PM, Robert Collins wrote: On 30 July 2015 at 01:39, Sean Dague wrote: So, after every release a giant amount of patches all have to land lock step or everything is broken? No, its not that bad. The *tagged* commit is fine forev

[openstack-dev] [os-ansible-deployment][openstack-ansible] Release review/bug list for tomorrow's meeting

Hi everyone, We need some support for reviews and bug updates, ideally before the next meeting at 16:00 UTC tomorrow as per https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting The following reviews are in-flight and are important for the upcoming releases, and the

Re: [openstack-dev] [magnum][blueprint] magnum-service-list

Suro, I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about renaming COE-specific command, since the new naming style looks consistent with other OpenStack projects. In addition, it will eliminate name collision of different COEs. Also, if we are going to support pluggable COE,

[openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer

Hi I have manually installed latest ceilometer service in my devstack (master branch) cluster with MongoDB as backend. I have configured all the ceilometer services (notification, central, collector, api services on controller node and ceilometer-agent-compute on compute nodes) as per the inst

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

On 7/29/15, 13:27, "William M Edmonds" wrote: > >> From: Doug Hellmann >> To: openstack-dev >> Date: 07/28/2015 07:59 PM >> Subject: Re: [openstack-dev] [glance] Removing python-swiftclient > >> from requirements.txt >> > > > >> I replied on both patches, but I'll repeat it here for a broade

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 30 July 2015 at 09:02, Matt Riedemann wrote: > > > On 7/29/2015 12:45 PM, Sean Dague wrote: >> >> I thought Matt said there was a coupling here between stable/kilo and >> master. That would imply that all of master would need changes as well, >> right? And block merges until stable is fixed fo

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

On 30 July 2015 at 05:45, Sean Dague wrote: > On 07/29/2015 01:21 PM, Robert Collins wrote: >> However - see above - I think the impact of the release is being >> overstated. If I have that wrong, please help me understand whats >> happened here. > > I thought Matt said there was a coupling here

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

On 30 July 2015 at 02:48, Doug Hellmann wrote: > Excerpts from Louis Taylor's message of 2015-07-29 15:25:33 +0100: >> On Tue, Jul 28, 2015 at 07:55:54PM -0400, Doug Hellmann wrote: >> > I replied on both patches, but I'll repeat it here for a broader >> > audience: >> > >> > Please set up an "ext

Re: [openstack-dev] [magnum][blueprint] magnum-service-list

Hi Hongbin, What would be the value of having COE-specific magnum command to go and talk to DB? As in that case, user may use the native client itself to fetch the data from COE, which even will have latest state. In a pluggable architecture there is always scope for common abstraction and d

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

On 30 July 2015 at 09:38, Ian Cordasco wrote: > > > On 7/29/15, 13:27, "William M Edmonds" wrote: > >> >>> From: Doug Hellmann >>> To: openstack-dev >>> Date: 07/28/2015 07:59 PM >>> Subject: Re: [openstack-dev] [glance] Removing python-swiftclient >> >>> from requirements.txt >>> >> >> >> >>>

Re: [openstack-dev] [fuel][puppet] Fuel Library and upstream modules

On 07/29/2015 03:48 PM, Alex Schultz wrote: > Hello everyone, > > I have put together a wiki describing the proposed interactions between > fuel-library and upstream modules based on previous talks around > librarian-puppet[0]. Please take some time to > review https://wiki.openstack.org/wiki/F

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

> I think pushing them up earlier would indeed make it easier for folk. Indeed, but it's too late now. > But its not as good as using post-versioniing :) Agreed, after 2015.1.2 version bumps are merged, I'll propose version= line removals on stable branches so this situation doesn't happen again

[openstack-dev] [app-catalog] IRC Meeting Thursday July 30th at 17:00UTC

Hello! Our next OpenStack App Catalog meeting will take place this Thursday July 20th at 17:00 UTC in #openstack-meeting-3 The agenda can be found here: https://wiki.openstack.org/wiki/Meetings/app-catalog Please add agenda items if there's anything specific you would like to discuss. For this w

[openstack-dev] [Tacker][NFV] Tacker mid-cycle meetup in Aug @ San Jose

Tacker team is planning a Liberty Mid-cycle meet-up. https://etherpad.openstack.org/p/liberty-tacker-midcycle When: Aug 20th - 21st Where: San Jose, CA Agenda: Thursday Aug 20th - 1:30pm - 6pm - Tacker Hackathon *for developers planning to contribute to Tacker, new members welcome!* Frid

[openstack-dev] [ironic] baremetal server boot failing at iSCSI/tgtd

Hi, I am trying to boot an instance using pxe deployment process.I am using cirros-0.3.4-x86_64-uec image to boot the baremetal server VM.ramdisk and kernel images are being deployed successfully , but at kernel initialization time its getting stuck there.In console logs I can see that tgtd daemon

[openstack-dev] [nova] Nova API team meeting

Hi, We have weekly Nova API meeting this week. The meeting is being held tomorrow Friday UTC1200. In other timezones the meeting is at: EST 08:00 (Fri) Japan 21:00 (Fri) China 20:00 (Fri) United Kingdom 13:00 (Fri) The proposed agenda and meeting details are here: https://wiki.openstack.org/w

Re: [openstack-dev] [keystone] the status of ec2 api

Hi Brant, 2015-07-30 3:50 GMT+09:00 Brant Knudson : >> On Mon, Jul 13, 2015 at 9:50 PM, Ken'ichi Ohmichi >> wrote: >>> >>> Hi Keystone team, >>> >>> Now the test of ec2 credentials[1] is been proposed to Tempest, and >>> I'd like to know current situation of ec2 api on Keystone as a Tempest >>> r

Re: [openstack-dev] [packaging][all] setting minimum version of setuptools in setup.py

I agree an error message is better than breaking for insane reasons. But... maybe as an aside... what about not breaking? How come the openstack ecosystem doesn't have wait for PEP 426 to be approved and for setuptools 17.1 to be widely deployed before it can require/depend on it? Is there no fa

  1   2   >