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:emil...@redhat.com] > > Sent: May-11-16 9:44 AM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev]

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

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

[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

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

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,

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:nik.koma...@gmail.com] > Sent: Wednesday, May 11, 2016 8:40 PM > To: OpenStack Development Mailing List

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

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

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

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

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 >

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

[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

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.

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]

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

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.

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

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

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

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

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 >

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

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

[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

[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

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

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

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

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

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

[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

[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

[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

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: "hu.zhiji...@zte.com.cn"

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

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

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,

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

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

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 > wrote: On 05/11/2016 11:51 PM, Flavio Percoco wrote: Greetings, The Glance team is evaluating the

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

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

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

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

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) < erh...@bloomberg.net> 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:

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

[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

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

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

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

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

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

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

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] [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] [cinder][nova] Multi-attach/Cinder-Nova weekly IRC meetings

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

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

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

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

[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

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

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

[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

[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

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

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

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

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:

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

[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://hu...@review.openstack.org/openstack/kolla.git (fetch) gerrit

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

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

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

On 12/05/16 02:59, "Nikhil Komawar" wrote: >Thanks Josh about your reply. It's helpful. > >The attempt of this cross project work is to come up with a standard way >of implementing quota logic that can be used by different services. >Currently, different projects have

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

On 2016-05-12 02:59, Nikhil Komawar wrote: > Thanks Josh about your reply. It's helpful. > > The attempt of this cross project work is to come up with a standard way > of implementing quota logic that can be used by different services. > Currently, different projects have their individual

[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

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

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: dolph.math...@gmail.com 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: >

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?

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

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] [keystone] Need info on the correct location to place the certificates / correct tags to specify the same

Hi All, While upgrading from Kilo to Liberty, I am seeing these warnings in the logs:- ./keystone/keystone.log:2016-05-11 13:40:34.013 20402 WARNING oslo_config.cfg [-] Option "certfile" from group "ssl" is deprecated. Use option "certfile" from group "eventlet_server_ssl".

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

Hi, My concern is that using option 1 is acceptable or not (because it’s not implemented yet.) So, first step, I’ll implement bp:bay-with-no-floating-ips using option 1, and option2 or 3 will be implemented later if

Re: [openstack-dev] [openstack-operators] [glance] Austin summit summary: Rolling upgrades

Can we start some background research on this topic? This ties up very well with deprecating registry and it would be nice if we can determine if registry is useful or not especially if we use different types of rolling upgrade schemes (direct oslo.vo, expand/contract, etc.) On 5/5/16 2:06 AM,

Re: [openstack-dev] [ironic] Summit recap

Hi, Jim, thank you for recap and blog! > # Newton priorities > > [Etherpad]( https://etherpad.openstack.org/p/ironic-newton-summit-priorities) > > We discussed our priorities for the Newton cycle here. > > Of note, we decided that we need to get cold upgrade testing (i.e. > grenade) running

Re: [openstack-dev] [magnum][higgins][all] The first Higgins team meeting

Hongbin, Will the activities within the project be related to container orchestration systems (Kubernetes, Mesos, Swarm), or they will still live in the world of Magnum? Ihor On Wed, May 11, 2016 at 8:33 AM Hongbin Lu wrote: > Hi all, > > > > I am happy to announce that

Re: [openstack-dev] [magnum][higgins][all] The first Higgins team meeting

Ihor, Please see the notes from first meeting: http://eavesdrop.openstack.org/meetings/higgins/2016/higgins.2016-05-13-03.01.log.html On Thu, May 12, 2016 at 11:10 PM, Ihor Dvoretskyi wrote: > Hongbin, > > Will the activities within the project be related to container

[openstack-dev] [tricircle]PTL Candidacy for Tricircle in Newton release

I am Chaoyi Huang, would like to propose my candidacy for the Tricircle PTL in Newton. I have been working on the Tricircle from day one, from the open source development since June,2015, and even from the PoC of OpenStack cascading solution. My passion to work on Tricircle is that Tricircle

[openstack-dev] [barbican]barbican-worker and barbican-keystone-listener not starting up

Hi, I have a 4 node setup of openstack liberty. 1 controller , 2 compute node and 1 network node. I did a apt-get barbican-api barbican-worker barbican-keystone-listener and installed the components. The deployment is pointing to the ubuntu liberty repository. The database used by all the services

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

We find glance registry quite useful. Have a central glance-registry api is useful when you have multiple datacenters all with glance-apis and talking back to a central registry service. I guess they could all talk back to the central DB server but currently that would be over the public

Re: [openstack-dev] [tacker]ad-hoc meeting of May 16

UTC 16:00 is too late for most of senlin developers to join. Still interested in the outcomes from this discussion. Regards, Qiming On Thu, May 12, 2016 at 11:59:37PM +, Bruce Thompson (brucet) wrote: > Hi, > > IRC meeting: https://webchat.freenode.net/?channels=tacker on Monday 16 >

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

I have been of the same opinion as far as upgrades go. I think we are stepping ahead of ourselves here a bit. We need to figure out the rolling upgrade story first and see if registry is actually useful or not there as well. The feedback from operator sessions also indicated that some ops do use

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

Thanks for explaining that - I thought I was going mad. You're right about implementation challenges! TBH, I'm writing something that would work at least in our environment and trying to keep it as small and simple as possible so we can maintain it - currently one of our dev team is adding a

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,

  1   2   >