Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

Hi, I have a question on js-openstacklib. If it is intended for browsers, there will be lots of issues with cross-domain security policy, browser cannot just go to any REST resource it wants. There is either some server-side proxy required or cooperation of the all the REST services we want to tal

[openstack-dev] [kolla] How to contribute to kolla

Hi all kolla fellows, Previously, I managed submit a code review to kolla repo but now I couldn't. Do I need additional rights or configurations? Below is my git remote -a output: gerrit https://[email protected]/openstack/kolla.git (fetch) gerrit https://[email protected]/o

Re: [openstack-dev] [ironic][nova][neutron][qa] Injecting code into grenade resource create phase

Hello Jim, Thanks for rising this question. My personal feeling that we don't need to tune tests that won't pass due to design limitations. It is Ironic pre-requirement to have network access from control plane to server during provisioning. Until Ironic Neutron integration is completed we may sk

Re: [openstack-dev] [magnum] Jinja2 for Heat template

Hi, not sure why 3 will bring chaos when implemented properly. Can you abstract the "thing" (sorry, not quite familiar with Magnum) that needs FP + FP itself into a custom resource/nested stack? Then you could use single master template plus two environments (one with FP, one without), and choose

Re: [openstack-dev] [TripleO] Undercloud Configuration Wizard

On 05/11/2016 06:19 PM, Ben Nemec wrote: Hi all, Just wanted to let everyone know that I've ported the undercloud configuration wizard to be a web app so it can be used by people without PyQt on their desktop. I've written a blog post about it here: http://blog.nemebean.com/content/undercloud-c

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

Hi Alexey, Thanks for clarified! I understood your use-case. Anyway, as Tim mentioned before, implementing Vitrage driver seems to be a good first step to integrate both. best regards, Masahito On 2016/05/10 20:00, Weyl, Alexey (Nokia - IL) wrote: Hi Masahito, In addition, I wanted to add

Re: [openstack-dev] [magnum] Jinja2 for Heat template

On Thu, May 12, 2016 at 11:08:02AM +0300, Pavlo Shchelokovskyy wrote: >Hi, > >not sure why 3 will bring chaos when implemented properly. I agree - heat is designed with composition in mind, and e.g in TripleO we're making heavy use of it for optional configurations and it works pretty wel

Re: [openstack-dev] [oslo] Austin summit session recap(s)

Doug Hellmann said on Wed, May 11, 2016 at 08:45:16AM -0400: > Yes, handler, sorry. > > I thought they were only unconfigured if the flag was set to do that, > and that your patch had the disable_existing_loggers flag set to not do > it? Maybe I misunderstood the full meaning of the flag, though,

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

Hi Dolph, On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote: > > On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert > wrote: > Hi, > > we're deploying Liberty (soon Mitaka) with heavy reliance on > the SAML2 > Federation system by Keystone where we're

Re: [openstack-dev] [kolla] How to contribute to kolla

Try setup your HTTP password on gerrit by clicking 'settings'. Say you have a HTTP password 'abcdef', then your 'gerrit' remote should look like: [remote "gerrit"] url = https://huzhj:[email protected]/openstack/kolla.git fetch = +refs/heads/*:refs/remotes/gerrit/* This is how we fr

Re: [openstack-dev] [tc] supporting Go

On Mon, 9 May 2016 at 19:32 Monty Taylor wrote: [...] > [> The point here though, is that the versions of Python that OpenStack > > has traditionally supported have been directly tied to what the Linux > > distributions carry in their repositories (case in point, Python 2.6 > > was dropped from m

Re: [openstack-dev] [magnum] Jinja2 for Heat template

Hi, Thanks for your helpful comment. I didn’t know about the pattern you suggested. We often want to “if” or “for” etc… For example, * if private network is supplied as parameter, disable creating network resource. * if https parameter is enable, tcp 6443 port should be opened instead of 8080 at“

Re: [openstack-dev] [magnum] How to document 'labels'

I prefer option 1 with 3, which is easy to maintain. and also accounting for user experience. for option 2, is it really good to expose helpful message in API layer ? Thanks. Best Wishes, Kai Qiang Wu (吴开强 Kenna

Re: [openstack-dev] [ironic][nova][neutron][qa] Injecting code into grenade resource create phase

On 05/11/2016 05:53 PM, Jim Rollenhagen wrote: > I've ran into a bit of a wedge working on ironic grenade tests. > > In a normal dsvm run, the ironic setup taps the control plane into the > tenant network (as that's how it's currently intended to be deployed). > That code is here[0]. > > However,

Re: [openstack-dev] [ironic][nova][neutron][qa] Injecting code into grenade resource create phase

Its easy enough to setup devstack today to use a flat neutron network instead of faking it using the tenant networks which we don¹t support, I do it in my third party CI for real hardware, if we can make it work for fake BM VMs too would it solve this issue, or would grenade override that? For ref

Re: [openstack-dev] [javascript] [infra] NPM Mirrors (IMPORTANT)

Hi, Michael, I randomly get "error parsing json" for fuel-ui project: http://paste.openstack.org/show/496871/. Got such errors 2 times out of 5. 2016-05-11 22:07 GMT+03:00 Michael Krotscheck : > Hello everyone! > > We've recently added NPM mirrors to our in

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

Tim Bell wrote: [...] I think it will be really difficult to persuade the mainstream projects to adopt a library if it is not part of Oslo. Developing a common library for quota management outside the scope of the common library framework for OpenStack does not seem to be encouraging the widespre

Re: [openstack-dev] [ironic][nova][neutron][qa] Injecting code into grenade resource create phase

On Thu, May 12, 2016 at 06:48:02AM -0400, Sean Dague wrote: > On 05/11/2016 05:53 PM, Jim Rollenhagen wrote: > > I've ran into a bit of a wedge working on ironic grenade tests. > > > > In a normal dsvm run, the ironic setup taps the control plane into the > > tenant network (as that's how it's cur

Re: [openstack-dev] [ironic][nova][neutron][qa] Injecting code into grenade resource create phase

On Thu, May 12, 2016 at 10:51:57AM +0300, Vasyl Saienko wrote: > Hello Jim, > > Thanks for rising this question. > > My personal feeling that we don't need to tune tests that won't pass due to > design limitations. > It is Ironic pre-requirement to have network access from control plane to > serv

Re: [openstack-dev] [tc] supporting Go

Robert Collins wrote: [...] So, given that that is the model - why is language part of it? Yes, there are minimum overheads to having a given language in CI [...] By "minimum" do you mean that they are someone else's problem ? There are economics at play here. Adding a language simplifies the

Re: [openstack-dev] [glance] [VMT] [Security] Proposal to add Brian Rosmaita to the glance-coresec team

+1 On May 11, 2016 11:48 PM, "Bhandaru, Malini K" wrote: > +1 :-) > > -Original Message- > From: Nikhil Komawar [mailto:[email protected]] > Sent: Wednesday, May 11, 2016 8:40 PM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [glance] [VMT] [Security] Proposal

[openstack-dev] [neutron] Diagnostics spec review

Adding diagnostics capabilities to Neutron has been requested by several recent RFEs. I have tried to consolidate features requested in them and incorporate points from Austin design session on diagnostics & troubleshooting into a specification on that topic [1]. If you are interested in enhanc

Re: [openstack-dev] [glance] [VMT] [Security] Proposal to add Brian Rosmaita to the glance-coresec team

On 2016-05-11 23:39:58 -0400 (-0400), Nikhil Komawar wrote: > I would like to propose adding add Brian to the team. [...] I'm thrilled to see Glance adding more security-minded reviewers for embargoed vulnerability reports! One thing to keep in mind though is that you need to keep the list of peop

Re: [openstack-dev] [ironic] Midcycle: virtual or physical?

Friendly reminder to take this poll; I see at least a few cores missing here. // jim On Tue, May 10, 2016 at 03:32:23PM +, Loo, Ruby wrote: > The poll closes Sunday night/Monday morning. Ie, whenever Jim gets around to > looking at the numbers Monday (May 16) morning, before our weekly ironi

Re: [openstack-dev] Easing contributions to central documentation

On Thu, May 12, 2016 at 1:24 AM, Joseph Robinson wrote: > Hi All, One reply inline: > > On 11/05/2016, 7:33 AM, "Lana Brindley" wrote: > >>On 10/05/16 20:08, Julien Danjou wrote: >>> On Mon, May 09 2016, Matt Kassawara wrote: >>> So, before developer frustrations drive some or all projects t

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

+1 on desiring OAuth-style tokens in Keystone. The use cases that come up here are people wanting to be able to execute jobs that use the APIs (Jenkins, Terraform, Vagrant, etc.) without having to save their personal credentials in plaintext somewhere, and also wanting to be able to associate cr

Re: [openstack-dev] [glance] [VMT] [Security] Proposal to add Brian Rosmaita to the glance-coresec team

+1 -Hemanth From: Nikhil Komawar Sent: Wednesday, May 11, 2016 10:39 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [glance] [VMT] [Security] Proposal to add Brian Rosmaita to the glance-coresec team Hello all, I would like to propos

Re: [openstack-dev] [tc] supporting Go

James, Thanks for the detailed write up straight from the trenches :) -- Dims On Thu, May 12, 2016 at 5:58 AM, James Page wrote: > On Mon, 9 May 2016 at 19:32 Monty Taylor wrote: > [...] >> >> [> The point here though, is that the versions of Python that OpenStack >> > has traditionally suppor

Re: [openstack-dev] [puppet] magnum module - fixes/improvements for Mitaka release

On Wed, May 11, 2016 at 7:47 PM, Hongbin Lu wrote: > > > > -Original Message- > > From: Emilien Macchi [mailto:[email protected]] > > Sent: May-11-16 9:44 AM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [puppet] magnum module - > >

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

Hello there, Anton- In Mitaka, most of OpenStack's services have landed CORS support. While it's not yet "Automagic" (i.e. it still requires some manual configuration), we no longer have to rely on any server component to render a user interface. The big outstanding things we need to do for CORS

Re: [openstack-dev] [javascript] [infra] NPM Mirrors (IMPORTANT)

Thanks, Vitaly- I'll add it to the list of things to investigate. I suspect it might be a cold cache, however trusting my gut when it comes to javascript related things has burned me in the past. Michael On Thu, May 12, 2016 at 4:10 AM Vitaly Kramskikh wrote: > Hi, Michael, > > I randomly get "

Re: [openstack-dev] Easing contributions to central documentation

I'm also not a fan of option 3 because it trades one kind of technical debt for another. However, one could argue that some (relevant) content is better than no (or defunct) content. Interestingly, option 3 also reflects what ultimately happens if projects decide to maintain all documentation in th

Re: [openstack-dev] Easing contributions to central documentation

On 2016-05-12 07:33:35 -0600 (-0600), Matt Kassawara wrote: [...] > I'm also not a fan of option 3 because it trades one kind of technical debt > for another. However, one could argue that some (relevant) content is > better than no (or defunct) content. Interestingly, option 3 also reflects > what

Re: [openstack-dev] Easing contributions to central documentation

On 2016-05-12 15:39, Jeremy Stanley wrote: > On 2016-05-12 07:33:35 -0600 (-0600), Matt Kassawara wrote: > [...] >> I'm also not a fan of option 3 because it trades one kind of technical debt >> for another. However, one could argue that some (relevant) content is >> better than no (or defunct) con

[openstack-dev] [ironic][openstackclient] deprecation process

Hi OpenStackClient folks, Ironic is following the standard deprecation process [1]. We added an OSC plugin and realized that we didn’t get the commands quite right. This patch [2] adds the right commands and deprecates the wrong ones. My question is what the deprecation process might be. Since

Re: [openstack-dev] [ironic] [OpenstackClient] deprecations

Thanks Jim, for explaining why ironic doesn¹t have that governance tag yet. I didn¹t (except now, need caffeine obviously) see the OpenStackClient tag added to the subject line and thought you had forgotten and so just fired off another ³cleaner² email about it. Oops. Apologies to everyone for t

Re: [openstack-dev] Easing contributions to central documentation

On Tue, May 10, 2016 at 12:40 AM, Matt Kassawara wrote: > At each summit, I speak with a variety of developers from different > projects about the apparent lack of contributions to the central > documentation. At previous summits, the most common complaint involved > using DocBook. After converti

Re: [openstack-dev] [magnum] How to document 'labels'

+1 for 1 and 3. I'm not sure maintainability should discourage us from exposing information to the user through the client - we'll face the same maintenance burden as we currently do, and IMO it's our job as a team to ensure our docs are up-to-date. Any kind of input which touches the API shou

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

Hi, If I may bring some insights from the distro's viewpoint... On 04/21/2016 04:35 PM, Michael Krotscheck wrote: > New: Xenial Build Nodes > > As of two weeks ago, OpenStack’s Infrastructure is running a version of > Node.js and npm more recent than what is available on Trusty LTS. > Ultimately

Re: [openstack-dev] [fuel] switch to upstream haproxy module

Hi Alex, Collapsing our haproxy tasks makes it a bit trickier for plugin developers. We would still be able to control it via hiera, but it means more effort for a plugin developer to run haproxy for a given set of services, but explicitly exclude all those it doesn't intend to run on a custom rol

[openstack-dev] [fuel] switch to upstream haproxy module

Hey Fuelers, We have been using our own fork of the haproxy module within fuel-library for some time. This also includes relying on a MOS specific version of haproxy that carries the conf.d hack. Unfortunately this has meant that we've needed to leverage the MOS version of this package when deplo

Re: [openstack-dev] [fuel] switch to upstream haproxy module

On Thu, May 12, 2016 at 8:39 AM, Matthew Mosesohn wrote: > Hi Alex, > > Collapsing our haproxy tasks makes it a bit trickier for plugin > developers. We would still be able to control it via hiera, but it > means more effort for a plugin developer to run haproxy for a given > set of services, but

[openstack-dev] [kuryr] Port binding query

I'm trying Kuryr with networking-calico and think I've hit an unhelpful inconsistency. A Neutron port has 'id' and 'device_id' fields that are usually different. When Nova does VIF binding for a Neutron port, it generates the Linux device name from 'tap' + port['id']. But when Kuryr does VIF bindin

[openstack-dev] [requirements] [packaging] How can Upper Constraints be used by packagers

Hello. *Background: * Linux packages like DEB/RPM have “Depends:” clauses, Currently packagers use the global-requirements.txt (via requirements.txt) to come up with the version range for this “Depends: || Requires:” clause. *Example :* [deb] http://noodle.portalus.net/debian/pool/main/n/nova/n

Re: [openstack-dev] Easing contributions to central documentation

On 09/05/16 22:57, Matt Kassawara wrote: > At each summit, I speak with a variety of developers from different > projects about the apparent lack of contributions to the central > documentation. At previous summits, the most common complaint involved > using DocBook. After converting most of the do

[openstack-dev] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps

Hi folks, Although the Identity v2 API is deprecated as of Mitaka [1], some services haven't implemented proper support to v3 yet. For instance, we implemented a patch that made DevStack v3 by default that, when merged, broke a lot of project gates in a few hours [2]. This happened due to specific

[openstack-dev] [freezer] Newton Summit Freezer Sessions Recap

Hello everyone, Here is the recap of what happened during the Newton Summit in Austin concerning Freezer: We had one presentation animated by Fausto Marzi (daemontool) and Fabrizio Fresco (frescof) and as well as four developper sessions. Overall, we have noticed a large attendance and a big in

Re: [openstack-dev] [kolla] How to contribute to kolla

Hu, I'd recommend joining irc and asking on #openstack-infra. They can help you live debug your connection to gerrit. I have also seen Qiming's response, which may or may not help. Regards -steve From: "[email protected]" mailto:[email protected]>>

Re: [openstack-dev] [glance] glance-registry deprecation: Request for feedback

On 05/11/2016 11:51 PM, Flavio Percoco wrote: Greetings, The Glance team is evaluating the needs and usefulness of the Glance Registry service and this email is a request for feedback from the overall community before the team moves forward with anything. Historically, there have been reasons t

[openstack-dev] [Neutron][ML2][Routed Networks]

Hi, Segments are now a first class thing in Neutron with the merge of this patch [1]. It exposes API for segments directly. With ML2, it is currently only possible to view segments that have been created through the provider net or multi-provider net extensions. This can only be done at network

Re: [openstack-dev] [magnum] Jinja2 for Heat template

We discussed the management of Heat templates several times. It seems the consensus is to leverage the *conditionals*feature from Heat (option #1). From the past discussion, it sounds like option #2 or #3 will significantly complicate our Heat templates, thus incurring burden on maintenance. Ho

Re: [openstack-dev] [glance] glance-registry deprecation: Request for feedback

On Thu, May 12, 2016 at 4:23 PM, Jay Pipes wrote: > On 05/11/2016 11:51 PM, Flavio Percoco wrote: > >> Greetings, >> >> The Glance team is evaluating the needs and usefulness of the Glance >> Registry >> service and this email is a request for feedback from the overall >> community >> before the

Re: [openstack-dev] [glance] glance-registry deprecation: Request for feedback

Gotcha. In that case, yeah, kill it :) On 05/12/2016 11:41 AM, Erno Kuvaja wrote: On Thu, May 12, 2016 at 4:23 PM, Jay Pipes mailto:[email protected]>> wrote: On 05/11/2016 11:51 PM, Flavio Percoco wrote: Greetings, The Glance team is evaluating the needs and usefulness o

[openstack-dev] [Ironic] Changes to Ramdisk and iPXE defaults in Devstack and many gate jobs

Hi all, A change (https://review.openstack.org/#/c/313035/) to Ironic devstack is in the gate, changing the default ironic-python-agent (IPA) ramdisk from CoreOS to TinyIPA, and changing iPXE to default enabled. As part of the work to improve and speed up gate jobs, we determined that using

Re: [openstack-dev] [kuryr] Port binding query

On Thu, May 12, 2016 at 4:50 PM, Neil Jerram wrote: > I'm trying Kuryr with networking-calico and think I've hit an unhelpful > inconsistency. A Neutron port has 'id' and 'device_id' fields that are > usually different. When Nova does VIF binding for a Neutron port, it > generates the Linux devic

Re: [openstack-dev] [fuel] switch to upstream haproxy module

First of all, I'm +1 on this. But as Matt says, it needs to take care of the plugins. A few examples I know of are the Zabbix plugin [1] and the LMA collector plugin [2] that modify the HAProxy configuration of the controller nodes. How could they work with your patch? Simon [1] https://github.com

Re: [openstack-dev] [requirements] [packaging] How can Upper Constraints be used by packagers

On 05/12/2016 09:57 AM, Igor Yozhikov wrote: > > Hello. > > According to proposed changes in G-R > (https://etherpad.openstack.org/p/newton-global-requirements) related > to ranges/bounds I want to clarify situation for Linux packagers. > > Very often packages for requirements mentioned in requ

Re: [openstack-dev] [ironic][openstackclient] deprecation process

I thought we had this written down somewhere but I can't find it. The OSC deprecation process is two major releases. So if something was deprecated in L, it is removed in N. This goes for optional parameters being renamed / dropped, or commands being dropped / renamed. If an optional parameter is

Re: [openstack-dev] [fuel] switch to upstream haproxy module

On Thu, May 12, 2016 at 10:00 AM, Simon Pasquier wrote: > First of all, I'm +1 on this. But as Matt says, it needs to take care of > the plugins. > A few examples I know of are the Zabbix plugin [1] and the LMA collector > plugin [2] that modify the HAProxy configuration of the controller nodes.

[openstack-dev] [javascript] [eslint-config-openstack] ECMAScript 6 / ECMAScript2015 rules.

Fuel has already adopted ES6, and is moving to adopt eslint-config-openstack. To help them, Vitaly's started to propose language style rules for ES6, which are available to review at the below link: https://review.openstack.org/#/q/topic:es6+project:openstack/eslint-config-openstack Please take a

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

Responses inline: On 04/21/2016 04:35 PM, Michael Krotscheck wrote: > > New: Xenial Build Nodes > > > > As of two weeks ago, OpenStack’s Infrastructure is running a version of > > Node.js and npm more recent than what is available on Trusty LTS. > Update: We're now on xenial. Yay LTS! > > Ultim

Re: [openstack-dev] [fuel] switch to upstream haproxy module

On Thu, May 12, 2016 at 6:13 PM, Alex Schultz wrote: > > > On Thu, May 12, 2016 at 10:00 AM, Simon Pasquier > wrote: > >> First of all, I'm +1 on this. But as Matt says, it needs to take care of >> the plugins. >> A few examples I know of are the Zabbix plugin [1] and the LMA collector >> plugin

Re: [openstack-dev] [requirements] [packaging] How can Upper Constraints be used by packagers

Excerpts from Matthew Thode's message of 2016-05-12 11:01:52 -0500: > On 05/12/2016 09:57 AM, Igor Yozhikov wrote: > > > > Hello. > > > > According to proposed changes in G-R > > (https://etherpad.openstack.org/p/newton-global-requirements) related > > to ranges/bounds I want to clarify situatio

Re: [openstack-dev] [magnum] How to document 'labels'

I’d be in favor of 1. At the end of the man page or full help text, a URL could be useful for more information but since most people using the CLI will have to do a context change to access the docs, it is not a simple click but a copy/paste/find the browser window which is not so friendly. Ti

Re: [openstack-dev] [javascript] [eslint-config-openstack] ECMAScript 6 / ECMAScript2015 rules.

As of now, I've created review requests to enable all the rules used for Fuel UI except these: http://eslint.org/docs/rules/object-shorthand http://eslint.org/docs/rules/prefer-arrow-callback http://eslint.org/docs/rules/prefer-spread Enabling them will break valid ES5 code, and I didn't find a w

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200: > Tim Bell wrote: > > [...] > > I think it will be really difficult to persuade the mainstream projects to > > adopt > > a library if it is not part of Oslo. Developing a common library for quota > > management outside the scope

Re: [openstack-dev] [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings

On 04:07 May 12, Ildikó Váncsa wrote: > > > > -Original Message- > > From: Mike Perez [mailto:[email protected]] > > Sent: May 11, 2016 23:52 > > To: Ildikó Váncsa > > Cc: 'D'Angelo, Scott ([email protected])'; > > 'Walter A. Boring IV'; 'John Griffith > > ([email protected]

Re: [openstack-dev] Ansible inventory - Would you need another inventory system for your openstack cloud and how would you like it to be?

Monty Taylor wrote: > On 05/09/2016 09:27 AM, Jean-Philippe Evrard wrote: > > Hello everyone, > > > > I am using ansible for some time now, and I think the current default > > Ansible inventory system is lacking a few features, at least when > > working on an OpenStack cloud - whether it's for its

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

On 2016-05-12 16:27:43 + (+), Michael Krotscheck wrote: [...] > Has anyone agreed to do the work to include debian nodes in infra? > I know we've got Centos7 and Fedora23 now, adding Debian doesn't > seem like a huge stretch. We have "debian-jessie" images and workers in Nodepool already.

Re: [openstack-dev] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps

We just had to revert another v3 "fix" because it wasn't verified to work correctly in the gate - https://review.openstack.org/#/c/315631/ While I realize project-config patches are harder to test, you can do so with a bogus devstack-gate change that has the same impact in some cases (like the cas

Re: [openstack-dev] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps

On Thu, May 12, 2016 at 10:42 AM, Sean Dague wrote: > We just had to revert another v3 "fix" because it wasn't verified to > work correctly in the gate - https://review.openstack.org/#/c/315631/ > > While I realize project-config patches are harder to test, you can do so > with a bogus devstack-g

Re: [openstack-dev] [oslo] Austin summit session recap(s)

Excerpts from Alexis Lee's message of 2016-05-12 10:22:29 +0100: > Doug Hellmann said on Wed, May 11, 2016 at 08:45:16AM -0400: > > Yes, handler, sorry. > > > > I thought they were only unconfigured if the flag was set to do that, > > and that your patch had the disable_existing_loggers flag set t

Re: [openstack-dev] [glance] Newton priorities, processes, dates, spec owners and reviewers

Excerpts from Nikhil Komawar's message of 2016-05-12 01:44:06 -0400: > Hello all, > > Here are a few important announcements for the members involved in the > Glance community. > > > Priorities: > > === > > * The Glance priorities for Newton were discussed at the contributors' > meetup at

Re: [openstack-dev] [glance] Newton priorities, processes, dates, spec owners and reviewers

On 5/12/16 1:51 PM, Doug Hellmann wrote: > Excerpts from Nikhil Komawar's message of 2016-05-12 01:44:06 -0400: >> Hello all, >> >> Here are a few important announcements for the members involved in the >> Glance community. >> >> >> Priorities: >> >> === >> >> * The Glance priorities for Newt

Re: [openstack-dev] [magnum] How to document 'labels'

The canonical place for the help/documentation must be the online documentation. We must provide information in the docs first, additional content should be added to the CLI help. The labels field contains arbitrary metadata which can be consumed and used by the COE/bay, it has no set structure

Re: [openstack-dev] Ansible inventory - Would you need another inventory system for your openstack cloud and how would you like it to be?

On 2016-05-12 17:25:31 + (+), Sean M. Collins wrote: > Monty Taylor wrote: [...] > > Before we talk about making a new OpenStack Inventory for ansible, let's > > work on fixing the existing one. We just replaced the nova.py dynamic > > inventory plugin in the last year with the new openstac

Re: [openstack-dev] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps

On 05/12/2016 01:47 PM, Morgan Fainberg wrote: > This also comes back to the conversation at the summit. We need to > propose the timeline to turn over for V3 (regardless of > voting/non-voting today) so that it is possible to set the timeline that > is expected for everything to get fixed (and wh

[openstack-dev] [tripleo] sharing bits between nodes during deployment

Hi, During the recent weeks, we've noticed that some features would have a common challenge to solve: How to share informations or files between nodes, during a multi-node deployment. A few use-cases: * Deploying Keystone using Fernet tokens Adam Young started this topic a few weeks ago, we are

[openstack-dev] [release] Release countdown for week R-20, May 16-20

Focus - Teams should have published summaries from summit sessions to the openstack-dev mailing list and should be working on spec writing and review for priority features for this cycle. General Notes - I've proposed a patch to the release tools to change the tag in release anno

[openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

Hi everyone. I’ve recently found that straightforward use of NeutronDbObject is prone to concurrency-related problems. I’ve submitted a patch set [3] with some tests to show that without special treatment using NeutronDbObject could lead to unexpected results. Further patch sets will provide acq

Re: [openstack-dev] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps

On Thu, May 12, 2016 at 3:19 PM Sean Dague wrote: > On 05/12/2016 01:47 PM, Morgan Fainberg wrote: > > This also comes back to the conversation at the summit. We need to > > propose the timeline to turn over for V3 (regardless of > > voting/non-voting today) so that it is possible to set the tim

Re: [openstack-dev] [magnum] Jinja2 for Heat template

I’m in broad agreement with Hongbin. Having tried a patch to use jinja2 in the templates, it certainly adds complexity. I am in favor of using conditionals and consuming the latest version of heat. If we intend to support older versions of OpenStack this should be a clearly defined goal and need

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On 05/12/2016 09:07 AM, Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote: +1 on desiring OAuth-style tokens in Keystone. The use cases that come up here are people wanting to be able to execute jobs that use the APIs (Jenkins, Terraform, Vagrant, etc.) without having to save their personal credentials

[openstack-dev] [heat] [grenade] need for a testing phase?

I just discovered this - https://github.com/openstack/heat/blob/fed92fdd6e5a14ea658621375e528f1c0cbde944/devstack/upgrade/resources.sh#L41 in looking at why - https://review.openstack.org/#/c/315501/ did not pass on gate-grenade-dsvm-heat-nv Overloading resource create with a base smoke test is de

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

Hi Alexey, That sounds like a good use case. If I understand it correctly, the use case can be accomplished by doing two things: 1. Writing a Vitrage datasource driver that whenever it receives an alarm, pulls Vitrage's API. I'd recommend having the datasource driver pulling periodically, and a

Re: [openstack-dev] Ansible inventory - Would you need another inventory system for your openstack cloud and how would you like it to be?

On 05/12/2016 12:25 PM, Sean M. Collins wrote: > Monty Taylor wrote: >> On 05/09/2016 09:27 AM, Jean-Philippe Evrard wrote: >>> Hello everyone, >>> >>> I am using ansible for some time now, and I think the current default >>> Ansible inventory system is lacking a few features, at least when >>> wor

Re: [openstack-dev] [tc] supporting Go

On 13 May 2016 at 00:01, Thierry Carrez wrote: > Robert Collins wrote: >> >> [...] >> So, given that that is the model - why is language part of it? Yes, >> there are minimum overheads to having a given language in CI [...] > > > By "minimum" do you mean that they are someone else's problem ? No.

Re: [openstack-dev] [Neutron] Getting rid of lazy init for engine facade

Roman, thanks a lot for guidelines! I've updated the change and removed configure_db parameter. On Wed, May 11, 2016 at 4:58 PM, Roman Podoliaka wrote: > Hi Anna, > > Thank you for working on this in Neutron! > > EngineFacade is initialized lazily internally - you don't have to do > anything for

Re: [openstack-dev] [nova] api-ref sprint - Thursday Status - nova core reviewers needed

On 05/09/2016 08:23 AM, Sean Dague wrote: > There is a lot of work to be done to get the api-ref into a final state. > > Review / fix existing patches - > https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open > shows patches not yet merged. Please review them, and if the

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On Thu, May 12, 2016 at 8:10 AM Edmund Rhudy (BLOOMBERG/ 120 PARK) < [email protected]> wrote: > +1 on desiring OAuth-style tokens in Keystone. > OAuth 1.0a has been supported by keystone since the havana release, you just have to turn it on and use it: http://docs.openstack.org/developer/ke

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

Please find my response inline: On 5/12/16 1:10 PM, Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200: >> Tim Bell wrote: >>> [...] >>> I think it will be really difficult to persuade the mainstream projects to >>> adopt >>> a library if it is not part of

Re: [openstack-dev] [tripleo] sharing bits between nodes during deployment

On 05/12/2016 02:20 PM, Emilien Macchi wrote: Hi, During the recent weeks, we've noticed that some features would have a common challenge to solve: How to share informations or files between nodes, during a multi-node deployment. A few use-cases: * Deploying Keystone using Fernet tokens Adam

[openstack-dev] [Fuel] Fuel - Rack Scale Architecture integration

Hello Fuel team, I am a software engineer working in the OpenStack team at Intel. You may have heard of Rack Scale Architecture [1] that Intel is pioneering. It is a new data center architecture that "simplifies resource management and provides the ability to dynamically compose resources based

Re: [openstack-dev] [tc] supporting Go

My take would be to select no more than 3 languages, according what they are needed for, then let the Service Team pick the best one right for what it needs to be done. Something like: - Do you need more performance for this component in your service? OK, use this. - Do you need Web and alike? Ok

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400: > Please find my response inline: > > On 5/12/16 1:10 PM, Doug Hellmann wrote: > > Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200: > >> Tim Bell wrote: > >>> [...] > >>> I think it will be really difficult to

Re: [openstack-dev] [magnum] How to document 'labels'

I would like to add some context for a bigger picture so we might arrive at a more general solution. Typically CLI options are fairly static so the help messages are usually coded directly in the client. This provides a good user experience by making the info readily available to the users. The cas

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

I flubbed my description of what I had in mind - I was thinking of GitHub personal access tokens as a model, _not_ OAuth tokens. I believe the normal excuse is "inadequate caffeine". From: [email protected] Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

On 5/12/16 4:33 PM, Doug Hellmann wrote: > Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400: >> Please find my response inline: >> >> On 5/12/16 1:10 PM, Doug Hellmann wrote: >>> Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200: Tim Bell wrote: > [.

[openstack-dev] [glance] Focus for release week R-16 May 16-20

Hi Glancers, As per Doug's email [1], for R-16 the core team (and everyone else interested) is expected to focus on reviews for the following in the list of priority order: 1. Nikhil to publish remnant summaries, priority and process related commits to glance, glance-specs and ML (please review n

Re: [openstack-dev] [glance] [VMT] [Security] Proposal to add Brian Rosmaita to the glance-coresec team

Comments, alternate proposal inline. On 5/12/16 8:35 AM, Jeremy Stanley wrote: > On 2016-05-11 23:39:58 -0400 (-0400), Nikhil Komawar wrote: >> I would like to propose adding add Brian to the team. > [...] > > I'm thrilled to see Glance adding more security-minded reviewers for > embargoed vulne

  1   2   >