Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

Hello all, Harm, really appreciate all your reviews. You were always very thorough and insightful. You'll always be welcome back to the core team in the future. Thanks for everything Harm! +1 -Ryan - Original Message - From: "Michal Rostecki" To:

Re: [openstack-dev] [stable] kilo 2015.1.3 freeze exception request for cve fixes

On 15 January 2016 at 10:01, Thierry Carrez wrote: > Ihar Hrachyshka wrote: >> >> +1. CVE fixes obviously should be granted an exception. > > > +1 > Agreed, I have already +2'd on Gerrit. Can another core please do the same? Thanks -- Kind Regards, Dave Walker

Re: [openstack-dev] [nova][neutron][upgrade][devstack] Grenade multinode partial upgrade

Sean M. Collins wrote: Nice find. I actually pushed a patch recently that we should be advertising the MTU by default. I think this really shows that it should be enabled by default. https://review.openstack.org/263486l -- Sent from my Android device with K-9 Mail.

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On Fri, 15 Jan 2016, Thomas Goirand wrote: Whatever we choose, I think we should ban having copyright holding text within our source code. While licensing is a good idea, as it is accurate, the copyright holding information isn't and it's just missleading. I think we should not add new

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

Hi Thomas, good thoughts for a very important topic. I am currently refactoring a lot of code inside of the openstack-chef cookbooks and constantly have to ask myself, if i now have to add any copyright thingy to any file or am even allowed to delete the original copyright in a file after

Re: [openstack-dev] [nova][stable] Freeze exception for kilo CVE-2015-7548 backports

Matthew Booth wrote: The following 3 patches fix CVE-2015-7548 Unprivileged api user can access host data using instance snapshot: https://review.openstack.org/#/c/264819/ https://review.openstack.org/#/c/264820/ https://review.openstack.org/#/c/264821/ The OSSA is rated critical. The patches

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

My 2 cents on RabbitMQ logging... On Fri, Jan 15, 2016 at 8:39 AM, Michal Rostecki wrote: I'd suggest to check the similar options in RabbitMQ and other > non-OpenStack components. > AFAICT RabbitMQ can't log to Syslog anyway. But you have option to make RabbitMQ log to

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

Hello, I think creating a separate kolla-mesos meeting is a good idea. My only issue is that I'm a little afraid it might separate our community a little, but I think it's necessary for kolla-mesos to grow. My other thought is what is there to come of other kolla-* repos? That being not only

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

On 01/15/2016 11:14 AM, Simon Pasquier wrote: My 2 cents on RabbitMQ logging... On Fri, Jan 15, 2016 at 8:39 AM, Michal Rostecki > wrote: I'd suggest to check the similar options in RabbitMQ and other non-OpenStack components.

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

Thanks, as a hack that's not a bad fix. We maintain our own Horizon repo anyway and rebase often, so it's a change we can carry if needed. I'm just confused as to why these changes were made to work as they are. I mean sure having the html populate based on the form details is nice in

[openstack-dev] [all] [api] API Working Group Refresher

At yesterday's API Working Group meeting we decided it would be a good idea to send out a refresher on the existence of the group, its goals and activities. If you have interest in the improvement and standardization of OpenStack APIs please take this as an invitation to participate. The group

[openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

This isn't the first time I'm calling for it. Let's hope this time, I'll be heard. Randomly, contributors put their company names into source code. When they do, then effectively, this tells that a given source file copyright holder is whatever is claimed, even though someone from another company

Re: [openstack-dev] [stable] kilo 2015.1.3 freeze exception request for cve fixes

2016-01-15 11:08 GMT+01:00 Dave Walker : > On 15 January 2016 at 10:01, Thierry Carrez wrote: >> Ihar Hrachyshka wrote: >>> >>> +1. CVE fixes obviously should be granted an exception. >> >> >> +1 >> > > Agreed, I have already +2'd on Gerrit. Can another

[openstack-dev] [all] [api] Reminder about the State of WSME

I was checking the review queue for WSME earlier this week and discovered a few new patches and some patches that are mostly idling. This has inspired me to send out a reminder about the state of WSME, at least as it relates to OpenStack. Last summer when it seemed liked WSME was not being

[openstack-dev] [kolla] kolla-mesos IRC meeting

Hi, Currently we're discussing stuff about kolla-mesos project on kolla IRC meetings[1]. We have an idea of creating the separate meeting for kolla-mesos. I see the following reasons for that: - kolla-mesos has some contributors which aren't able to attend kolla meeting because of timezone

Re: [openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

On 14 January 2016 at 10:45, Michael Still wrote: > I think Tony would be a valuable addition to the team. +1 > +1 +1 John > On 14 Jan 2016 7:59 AM, "Matt Riedemann" wrote: >> >> I'm formally proposing that the nova-stable-maint team [1] adds

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

On Fri, Jan 15, 2016 at 11:57 AM, Michal Rostecki wrote: > On 01/15/2016 11:14 AM, Simon Pasquier wrote: >> >> My 2 cents on RabbitMQ logging... >> >> On Fri, Jan 15, 2016 at 8:39 AM, Michal Rostecki > > wrote: >> >>

Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

On 01/15/2016 01:12 AM, Steven Dake (stdake) wrote: Hi fellow core reviewers, Harm joined Kolla early on with great enthusiasm and did a bang-up job for several months working on Kolla. We voted unanimously to add him to the core team. Over the last 6 months Harm hasn't really made much

Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

That's an unfortunate +1, it's always sad to lose one of our own. Hope we'll see you back soon! Thanks for all the fis...reviews! On 15 January 2016 at 06:59, Ryan Hallisey wrote: > Hello all, > > Harm, really appreciate all your reviews. You were always very thorough and

Re: [openstack-dev] [stable] kilo 2015.1.3 freeze exception request for cve fixes

On 1/15/2016 4:13 AM, Alan Pevec wrote: 2016-01-15 11:08 GMT+01:00 Dave Walker : On 15 January 2016 at 10:01, Thierry Carrez wrote: Ihar Hrachyshka wrote: +1. CVE fixes obviously should be granted an exception. +1 Agreed, I have already +2'd

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

On Thu, 2016-01-14 at 16:04 -0500, Tzu-Mainn Chen wrote: > > - Original Message - > > On Wed, Jan 13, 2016 at 04:41:28AM -0500, Tzu-Mainn Chen wrote: > > > Hey all, > > > > > > I realize now from the title of the other TripleO/Mistral thread > > > [1] that > > > the discussion there may

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

Yeah that's true. We did all of openstack systems but we didn't implement infra around yet. I'd guess most of services can log either to stdout or file, and both sources should be accessible by heka. Also, I'd be surprised if heka wouldn't have syslog driver? That should be one of first:) Maybe

Re: [openstack-dev] [release] Release countdown for week R-11, Jan 18-22, Mitaka-2 milestone

Excerpts from Doug Hellmann's message of 2016-01-14 16:20:54 -0500: > Focus > - > > Next week is the second milestone for the Mitaka cycle. Major feature > work should be making good progress or be re-evaluated to see whether > it will really land this cycle. > > Release Actions >

Re: [openstack-dev] [Fuel] nova-network removal

I’d like to add that nova-network support was removed from python-fuelclient in 8.0. > 14 січ. 2016 р. о 17:54 Vitaly Kramskikh > написав(ла): > > Folks, > > We have a request on review which prohibits creating new envs with > nova-network:

[openstack-dev] Flame creates incorrect HEAT template for provider network

Hi OpenStack Flame developers, I see that the HEAT template generated by OpenStack Flame for a provider network is incorrect and has missing fields. For the provider network Provider_153, Flame creates the HEAT template network_0: properties: admin_state_up: true name:

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

As long as you guys do your best to attend normal Kolla meeting that's ok by me. Shame that probably we won't be able to attend because of out tz, but that's ok, we can read logs;) Just make sure to be part of kolla community as well, don't let separation like Ryan mentioned happen. +1 On 15

[openstack-dev] [openstack-ansible][security] Improving SSL/TLS in OpenStack-Ansible

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey folks, I've attended some of the OpenStack Security Mid-Cycle meeting this week and Robert Clark was kind enough to give me a deep dive on the Anchor project[1]. We had a good discussion around my original email thread[2] on improving

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 01/14/2016 08:04 PM, Jeremy Stanley wrote: > On 2016-01-14 22:14:09 + (+), Sean M. Collins wrote: > [...] >> The problem we have is - most operators are using Ubuntu according to >> the user survey. Most likely they are using LTS releases. We already get >> flack for our pace of

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On 2016-01-15 23:09:34 +0800 (+0800), Thomas Goirand wrote: > On 01/15/2016 09:57 PM, Jeremy Stanley wrote: [...] > > resulting in the summary at > > https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers for > > those who choose to learn from history rather than repeating it. > > Well,

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On 2016-01-15 07:31:09 -0600 (-0600), Dolph Mathews wrote: > This is a topic for legal-discuss, not -dev. > > http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss And not only that, but we've discussed it to death in years gone by (my how short some memories are), resulting in the

Re: [openstack-dev] [Fuel] nova-network removal

Although we are very close to HCF, I see no option but to continue removing nova-network as I understand it is not currently functional or well-tested for the Mitaka release. We must either remove it or test it, and we want to remove it anyway so that seems like the better path. *Mike*, what

Re: [openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

On 01/15/2016 03:45 PM, Victor Stinner wrote: > Hi, > > What are the issues? Is there a list of issues somewhere? > > Victor I reported a bunch of them, and so far, they seem fixed. Hopefully, I wont see some new or old ones for the B2 release. I'll post links to bugs in this thread if I

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

I’ve also seen the request multiple times to be able to provide more targeted snapshots which might also (partially) solve this problem as it would require significantly less disk space to grab logs from a subset of nodes for a specific window of time, instead of the more robust grab-all solution

Re: [openstack-dev] [cinder] Should we fix XML request issues?

Excerpts from Michał Dulko's message of 2016-01-15 09:08:54 +0100: > On 01/15/2016 07:14 AM, Jethani, Ravishekar wrote: > > Hi Devs, > > > > I have come across a few 500 response issues while sending request > > body as XML to cinder service. For example: > > > > > > > > I can see that XML

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On 01/15/2016 09:57 PM, Jeremy Stanley wrote: > On 2016-01-15 07:31:09 -0600 (-0600), Dolph Mathews wrote: >> This is a topic for legal-discuss, not -dev. >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss > > And not only that It is important that everyone writing code

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

> On 15 Jan 2016, at 14:57, Jeremy Stanley wrote: > > On 2016-01-15 07:31:09 -0600 (-0600), Dolph Mathews wrote: >> This is a topic for legal-discuss, not -dev. >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss > > And not only that, but we've

Re: [openstack-dev] [cinder] Should we fix XML request issues?

On Fri, Jan 15, 2016 at 09:08:54AM +0100, Michał Dulko wrote: > On 01/15/2016 07:14 AM, Jethani, Ravishekar wrote: > > Hi Devs, > > > > I have come across a few 500 response issues while sending request > > body as XML to cinder service. For example: > > > > > > > > I can see that XML

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

This is a topic for legal-discuss, not -dev. http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss On Friday, January 15, 2016, Thomas Goirand wrote: > This isn't the first time I'm calling for it. Let's hope this time, I'll > be heard. > > Randomly, contributors

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

On Thu, Jan 14, 2016 at 11:00:16AM +1300, Robert Collins wrote: > On 8 January 2016 at 08:09, Jim Rollenhagen wrote: > > Hi all, > > > > A change to global-requirements[1] introduces mimic, which is an http > > server that can mock various APIs, including nova and ironic,

Re: [openstack-dev] [cinder] Should we fix XML request issues?

500 error is bad for any API. IMO, I'm OK to fix it Mitaka. Deprecated means that it could be dropped soon. It doesn't mean that it's not working at all. BTW, XML API almost has no tests so I'm not surprised that it's broken Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Fri, Jan 15, 2016

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Sheena - What do you mean by *targeted*? Shotgun's designed to be a *targeted* solution. If someone wants more *precise* targets - it's easy to specify them in Nailgun's settings.yaml. - Igor On Fri, Jan 15, 2016 at 5:02 PM, Sheena Gregson wrote: > I’ve also seen the

Re: [openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

Hi All, I wonder whether we could provide an interface on the API where these kind of capabilities can be retrieved? I know we have a support matrix in the documentation that's good to have. I asked the question, because here we have a base functionality, which is attaching a volume that

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

I am -2 on a separate meeting. If there are problems with the current approach to how the agenda is managed as it relates to mesos topics, lets fix that. If there are timezone problems, lets try to fix that. Lets fix the problems you point out rather then create another meeting for our core

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

On 15 Jan 2016 at 14:43:39, Michał Jastrzębski (inc...@gmail.com) wrote: Yeah that's true. We did all of openstack systems but we didn't  implement infra around yet. I'd guess most of services can log either  to stdout or file, and both sources should be accessible by heka.  Also, I'd be surprised

[openstack-dev] [Neutron] MTU configuration pain

MTU has been an ongoing issue in Neutron for _years_. It's such a hassle, that most people just throw up their hands and set their physical infrastructure to jumbo frames. We even document it. http://docs.openstack.org/juno/install-guide/install/apt-debian/content/neutron-network-node.html >

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

It might be simpler to just update the label on the python code. This is where the form label are defined. You can update the label here: https://github.com/openstack/django_openstack_auth/blob/stable/kilo/openstack_auth/forms.py#L51 -Lin On Fri, Jan 15, 2016 at 12:54 AM, Itxaka Serrano Garcia

Re: [openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

> I'm formally proposing that the nova-stable-maint team [1] adds Tony > Breeds to the core team. My major complaint with Tony is that he talks funny. If he's willing to work on fixing that, I'm +1. :-P --Dan __ OpenStack

Re: [openstack-dev] [murano] Plugin installation issue

Hi Vahid, Sorry for the delayed response. I've run your plugin and I am facing an error during the loading of your plugin: the loader complains that it is unable to find the module named "heat_translator". As far as I can see, your plugin attempts the following import statement: *"from

[openstack-dev] [api] api working group proposed actions guideline needs input

In this review: https://review.openstack.org/#/c/234994/ there's a proposal that provides guidance for how to represent certains types of actions against resources in an HTTP API. There's been a fair bit of back and forth between me and the original author without conclusion. It would be

Re: [openstack-dev] [Fuel] nova-network removal

I agree with Sheena. Sounds like removing support for nova-network would be the best option, even though it's late. However, I'd like us to think about the impact on vCenter integration. vCenter+nova-network was fully supported before. Since we are now recommending DVS or NSX backends, I'd like

Re: [openstack-dev] [openstack-ansible][security] Should the playbook stop on certain tasks?

On 01/13/16 15:10, Major Hayden wrote: After presenting openstack-ansible-security at the Security Project Mid-Cycle meeting yesterday, the question came up around how to handle situations where automation might cause problems. For example, the STIG requires[1] that all system accounts other

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 2016-01-15 09:51:57 -0500 (-0500), Russell Bryant wrote: > but are most people using that LTS release with cloud-archive > enabled? I can't answer whether most Ubuntu users are adding it, though the (several) times we've tried to enable UCA in our test platforms in the past we've reported

Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

+1, hopefully we'll see Harm again in the future. Cheers, -Paul On 15/01/16 13:44, Michał Jastrzębski wrote: That's an unfortunate +1, it's always sad to lose one of our own. Hope we'll see you back soon! Thanks for all the fis...reviews! On 15 January 2016 at 06:59, Ryan Hallisey

Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

+1, I think this has been a good upholding of openstack core team policy. Always a nice reminder that any previous core member can be fast tracked back into place if they decide to become active again. On Fri, Jan 15, 2016 at 8:44 AM, Michał Jastrzębski wrote: > That's an

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On Fri, Jan 15, 2016 at 12:53:49PM +, Chris Dent wrote: > On Fri, 15 Jan 2016, Thomas Goirand wrote: > > >Whatever we choose, I think we should ban having copyright holding text > >within our source code. While licensing is a good idea, as it is > >accurate, the copyright holding information

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On Fri, Jan 15, 2016 at 08:48:21PM +0800, Thomas Goirand wrote: > This isn't the first time I'm calling for it. Let's hope this time, I'll > be heard. > > Randomly, contributors put their company names into source code. When > they do, then effectively, this tells that a given source file

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On 01/15/2016 10:28 AM, Daniel P. Berrange wrote: On Fri, Jan 15, 2016 at 12:53:49PM +, Chris Dent wrote: On Fri, 15 Jan 2016, Thomas Goirand wrote: Whatever we choose, I think we should ban having copyright holding text within our source code. While licensing is a good idea, as it is

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On 01/15/2016 10:38 AM, Daniel P. Berrange wrote: On Fri, Jan 15, 2016 at 08:48:21PM +0800, Thomas Goirand wrote: This isn't the first time I'm calling for it. Let's hope this time, I'll be heard. Randomly, contributors put their company names into source code. When they do, then effectively,

Re: [openstack-dev] Shovel (RackHD/OpenStack)

On Wed, Jan 13, 2016 at 09:56:57PM +, Heck, Joseph wrote: > Hey Jay! (yeah, I’m here and lurking in the corners, albeit with a > different email at the moment) > > Yep - RackHD was created by a company that was acquired by EMC to attack > the lowest-level of hardware automation. EMC was

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

Adrian, Changing the label is also possible through overrides, but customizing any label that goes through Localization might affect other languages. Not sure if this might be a problem for you. If this isn't ideal, we can easily put in hooks to allow customization purely through CSS, using

Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

I counted 6 votes in favor of removal. We have 10 people on our core team. A majority has been met and I have removed Harm from the core reviewer team. Harm, Thanks again for your helpful reviews and remember, your always welcome back in the future if your availability changes. For the

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

On Fri, Jan 15, 2016 at 7:44 AM Steven Dake (stdake) wrote: > I am -2 on a separate meeting. > > If there are problems with the current approach to how the agenda is > managed as it relates to mesos topics, lets fix that. If there are > timezone problems, lets try to fix that.

[openstack-dev] [mistral] N. Makhotkin availability next 2 weeks

Hi team! I will be on vacation next 2 weeks right till 31 Jan. Please ping me via email if I am needed for reviewing some patches. -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [app-catalog] Automating some aspects of catalog maintenance

The vast majority of projects are using a db to solve it. But that requires a db and a lot more API. Which we will get to when we go to glare. In the mean time, I suspect we're in fairly uncharted waters at the moment. Thanks, Kevin From: Christopher

[openstack-dev] [Neutron] Team meeting on Monday at 2100UTC

Hi folks, A reminder of next week meeting. Let's see if we manage to have the first one of the year! Word of notice: Monday is a public holiday for US. Cheers, Armando __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] Shovel (RackHD/OpenStack)

They’re definitely overlapping, but RackHD wasn’t created, and isn’t meant, to be specific to OpenStack, but as a more general purpose need for low level automation of hardware. Just like there’s Cobbler, Razor, and Hanlon out there - RackHD isn’t aiming to be OpenStack, just agnostic, and with

Re: [openstack-dev] Shovel (RackHD/OpenStack)

On 2016-01-15 18:44:42 + (+), Heck, Joseph wrote: [...] > I haven’t been following the community and the norms closely for a couple > years - Stackforge appears to have dissipated in favor of projects in > incubation to share things like this. Is that accurate? The idea of "incubating"

Re: [openstack-dev] [Fuel] nova-network removal

Adrian – can someone from the PI team please confirm what testing was performed? *From:* Roman Alekseenkov [mailto:ralekseen...@mirantis.com] *Sent:* Friday, January 15, 2016 11:30 AM *To:* OpenStack Development Mailing List (not for usage questions) < openstack-dev@lists.openstack.org>

Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

Hi guys, As Steven noted, activity from my side has dropped significantly, and with +2 comes a certain responsibility of at the very least keeping track of the codebase. Various reasons keep me from even doing that so this seems the logical outcome. Thanks for your support, it’s been a great

Re: [openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

We can give him elocution classes at the mid-cycle. It's like my fair lady, but nerdier. Michael On 16 Jan 2016 4:11 AM, "Dan Smith" wrote: > > I'm formally proposing that the nova-stable-maint team [1] adds Tony > > Breeds to the core team. > > My major complaint with Tony

Re: [openstack-dev] Shovel (RackHD/OpenStack)

Yep! Thanks Jim! ___ From: Jim Rollenhagen > Sent: Friday, January 15, 2016 5:48 PM Subject: Re: [openstack-dev] Shovel (RackHD/OpenStack) To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

A reason is the container abstraction brings containers to OpenStack: Keystone for authentication, Heat for orchestration, Horizon for UI, etc. From: Kyle Kelley [mailto:rgb...@gmail.com] Sent: January-15-16 10:42 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re:

Re: [openstack-dev] Long description of oslo.privsep

Haha, needs work :) -- Dims On Fri, Jan 15, 2016 at 10:53 PM, Thomas Goirand wrote: > On 01/16/2016 08:35 AM, Davanum Srinivas wrote: >> Zigo, >> >> Seriously, chill please. > > I was trying to write it funnily. Sorry if it wasn't obvious! :) > > Cheers, > > Thomas Goirand

Re: [openstack-dev] Shovel (RackHD/OpenStack)

Thanks for the links Jeremy! I'm still reading through what exactly "bigtent" means, not sure I grok the placement for littler/ancillary things like this effort, but the the links are hugely helpful! - joe _ From: Jeremy Stanley

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On 01/15/2016 11:38 PM, Daniel P. Berrange wrote: > On Fri, Jan 15, 2016 at 08:48:21PM +0800, Thomas Goirand wrote: >> This isn't the first time I'm calling for it. Let's hope this time, I'll >> be heard. >> >> Randomly, contributors put their company names into source code. When >> they do, then

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

Either 1 or 3. 2 does not solve anything. -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: Friday, January 15, 2016 10:01 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright

Re: [openstack-dev] Long description of oslo.privsep

Zigo, Seriously, chill please. the library is no where ready. It's not in global requirements either at the moment. the code quite a bit of time to go before we can switch over projects from oslo.rootwrap to oslo.privsep. We have check lists we that we go over before we let folks use it. Right

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

What are the reasons for keeping /containers? On Fri, Jan 15, 2016 at 9:14 PM, Hongbin Lu wrote: > Disagree. > > > > If the container managing part is removed, Magnum is just a COE deployment > tool. This is really a scope-mismatch IMO. The middle ground I can see is > to

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On 01/15/2016 11:26 PM, Jeremy Stanley wrote: > On 2016-01-15 23:09:34 +0800 (+0800), Thomas Goirand wrote: >> On 01/15/2016 09:57 PM, Jeremy Stanley wrote: > [...] >>> resulting in the summary at >>> https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers for >>> those who choose to

[openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

I filed a bug [1] a while ago that subnet_id should be an optional parameter for member creation. Currently it is required. Review [2] is makes it optional. The original thinking was that if the load balancer is ever connected to that same subnet, be it by another member on that subnet or the

Re: [openstack-dev] Long description of oslo.privsep

Hopefully the following helps out here. https://review.openstack.org/#/c/268377/ Gus or others hopefully can review that (and correct me if it's not the a good long description). -Josh Thomas Goirand wrote: Hi, Lucky I have written, in the cookie-butter repo: Please feel here a long

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

Disagree. If the container managing part is removed, Magnum is just a COE deployment tool. This is really a scope-mismatch IMO. The middle ground I can see is to have a flag that allows operators to turned off the container managing part. If it is turned off, COEs are not managed by Magnum and

Re: [openstack-dev] [all] Proposal: copyright-holders file in each project, or copyright holding forced to the OpenStack Foundation

On 01/15/2016 11:28 PM, Daniel P. Berrange wrote: > On Fri, Jan 15, 2016 at 12:53:49PM +, Chris Dent wrote: >> On Fri, 15 Jan 2016, Thomas Goirand wrote: >> >>> Whatever we choose, I think we should ban having copyright holding text >>> within our source code. While licensing is a good idea,

Re: [openstack-dev] Long description of oslo.privsep

On 01/16/2016 08:35 AM, Davanum Srinivas wrote: > Zigo, > > Seriously, chill please. I was trying to write it funnily. Sorry if it wasn't obvious! :) Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing List

Re: [openstack-dev] Long description of oslo.privsep

I have just approved that review, as it moves the ball in the right direction. Michael On Sat, Jan 16, 2016 at 3:04 PM, Davanum Srinivas wrote: > Haha, needs work :) > > -- Dims > > On Fri, Jan 15, 2016 at 10:53 PM, Thomas Goirand wrote: > > On 01/16/2016

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

I too believe that the /containers endpoint is obstructive to the overall goal of Magnum. IMO, Magnum’s scope should only be concerned with: 1. Provisioning the underlying infrastructure required by the Container Orchestration Engine (COE) and 2. Instantiating the COE itself on top of

[openstack-dev] OpenStack Developer Mailing List Digest January 9-15

Perma link: http://www.openstack.org/blog/2016/01/openstack-developer-mailing-list-digest-20160115/ Success Bot Says * stevemar: Latest python-neutronclient use keystoneauth, yay! * devkulkarni: Devstack plugin for Solum finally working as expected. * dulek: Initial tests show

Re: [openstack-dev] [stable] kilo 2015.1.3 freeze exception request for cve fixes

+1. CVE fixes obviously should be granted an exception. Matt Riedemann wrote: We should get this series in for nova in the kilo 2015.1.3 release: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:bug/1524274 -- Thanks,

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

Looks like the form comes from django_openstack_auth: https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/forms.py#L53 But to be honest, no idea how that can be overridden trough the themes, not sure if its even possible to override anything on that page without

Re: [openstack-dev] [cinder] Should we fix XML request issues?

On 01/15/2016 07:14 AM, Jethani, Ravishekar wrote: > Hi Devs, > > I have come across a few 500 response issues while sending request > body as XML to cinder service. For example: > > > > I can see that XML support has been marked as depricated and will be > removed in 'N' release. So is it

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

> > In case of MariaDB I see that you can > > - do --skip-syslog, then all things go to "error log" > - set "error log" path by --log-error > > So maybe setting stdout/stderr may work here? > > I'd suggest to check the similar options in RabbitMQ and other non-OpenStack > components. > > I may

[openstack-dev] [docs] Specialty teams wiki page moving to Contributor Guide

Good Friday to everyone! This is just a note that the Specialty Teams wiki page has been moved from wiki [1] to the Documentation Contributor Guide [2] as of now. Thanks and happy week-end! Olena [1] https://wiki.openstack.org/wiki/Documentation/SpecialityTeams [2]

Re: [openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

2016-01-14 17:12 GMT+01:00 Thomas Goirand : > On 01/14/2016 11:35 PM, Yuriy Taraday wrote: >> >> >> On Thu, Jan 14, 2016 at 5:48 PM Jeremy Stanley > > wrote: >> >> On 2016-01-14 09:47:52 +0100 (+0100), Julien Danjou wrote: >>

[openstack-dev] [Fuel] How to auto allocate VIPs for roles in different network node groups?

Hi, We need to come up with some solution for a problem with VIP generation (auto allocation), see the original bug [0]. The main problem here is: how do we know what exactly IPs to auto allocate for VIPs when needed roles are in different nodegroups (i.e. in different IP networks)? For example

[openstack-dev] [nova][stable] Freeze exception for kilo CVE-2015-7548 backports

The following 3 patches fix CVE-2015-7548 Unprivileged api user can access host data using instance snapshot: https://review.openstack.org/#/c/264819/ https://review.openstack.org/#/c/264820/ https://review.openstack.org/#/c/264821/ The OSSA is rated critical. The patches have now landed on

Re: [openstack-dev] [Fuel] How to auto allocate VIPs for roles in different network node groups?

On 15.01.2016 10:19, Aleksandr Didenko wrote: > Hi, > > We need to come up with some solution for a problem with VIP generation > (auto allocation), see the original bug [0]. > > The main problem here is: how do we know what exactly IPs to auto > allocate for VIPs when needed roles are in

Re: [openstack-dev] [stable] kilo 2015.1.3 freeze exception request for cve fixes

Ihar Hrachyshka wrote: +1. CVE fixes obviously should be granted an exception. +1 -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: