Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On Sun, May 14, 2017 at 6:59 PM, Monty Taylor wrote: > On 05/11/2017 02:32 PM, Lance Bragstad wrote: > >> Hey all, >> >> One of the Baremetal/VM sessions at the summit focused on what we need >> to do to make OpenStack more consumable for application developers [0]. >> As a

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 16:13, Colleen Murphy wrote: > On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak > > wrote: > > > > Tangentially related to this (because my reasons are different), > on our cloud I'm actually working on something like

[openstack-dev] [tripleo] Issue while applying customs configuration to overcloud.

Hi TripleO team, I am trying to apply custom configuration to an existing overcloud. (using openstack overcloud deploy command) Though there is no error, the configuration is in not applied to overcloud. Am I missing anything here? http://paste.openstack.org/show/609619/ Thanks and Regards,

[openstack-dev] [keystone] [Pile] Need Exemption On Submitted Spec for the Keystone

Hi Lance, We had submitted one blueprint and it’s Specs last weeks. Blueprint - https://blueprints.launchpad.net/keystone/+spec/api-implemetation-required-to-download-identity-policies Spec - https://review.openstack.org/#/c/463547/ As Keystone Pike

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

Flavio, Forgive the top post – outlook ftw. I understand the concerns raised in this thread. It is unclear if this thread is the feeling of two TC members or enough TC members care deeply about this issue to permanently limit OpenStack big tent projects’ ability to generate container images

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak wrote: > > > Tangentially related to this (because my reasons are different), on our > cloud I'm actually working on something like this, but under the hood all > I'm doing is creating a user with a generated password and

Re: [openstack-dev] [FaaS] Introduce a FaaS project

Hi, Rob, Appreciate your suggestions. Please see my inline comments. On Mon, May 15, 2017 at 11:17 PM, Robert Putt wrote: > For me the important things are: > > > > a) Sandboxed code in some container solution > Yeah, it's on the roadmap (may happen in

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 14:00, Adrian Turjak wrote: > > On 16/05/17 13:29, Lance Bragstad wrote: >> >> >> On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak >> > wrote: >> >> >> On 16/05/17 01:09, Lance Bragstad wrote: >>> >>> >>> On Sun, May 14,

Re: [openstack-dev] [tripleo][ci] Upgrade CI job for O->P (containerization)

On 12/05/17 09:30 -0400, Emilien Macchi wrote: On Wed, May 10, 2017 at 9:26 AM, Jiří Stránský wrote: Hi all, the upgrade job which tests Ocata -> Pike/master upgrade (from bare-metal to containers) just got a green flag from the CI [1]. I've listed the remaining patches we

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 15/05/17 12:32 -0700, Michał Jastrzębski wrote: On 15 May 2017 at 12:12, Doug Hellmann wrote: [huge snip] > I'm raising the issue here to get some more input into how to > proceed. Do other people think this concern is overblown? Can we > mitigate the risk by

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 13:29, Lance Bragstad wrote: > > > On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak > > wrote: > > > On 16/05/17 01:09, Lance Bragstad wrote: >> >> >> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor >>

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 15/05/17 11:49 -0700, Michał Jastrzębski wrote: On 15 May 2017 at 11:19, Davanum Srinivas wrote: Sorry for the top post, Michal, Can you please clarify a couple of things: 1) Can folks install just one or two services for their specific scenario? Yes, that's more of a

Re: [openstack-dev] [oslo][oslo.messaging] Call to deprecate the 'pika' driver in the oslo.messaging project

On 15/05/17 15:29 -0500, Ben Nemec wrote: On 05/15/2017 01:55 PM, Doug Hellmann wrote: Excerpts from Davanum Srinivas (dims)'s message of 2017-05-15 14:27:36 -0400: On Mon, May 15, 2017 at 2:08 PM, Ken Giusti wrote: Folks, It was decided at the oslo.messaging forum at

Re: [openstack-dev] [vitrage] [nova] VM Heartbeat / Healthcheck Monitoring

Hi Greg, In Masakari [0] for VMHA, we have already implemented some what similar function in masakri-monitors. Masakari-monitors runs on nova-compute node, and monitors the host, process or instance failures. Masakari instance monitor has similar functionality with what you have described.

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak wrote: > > On 16/05/17 01:09, Lance Bragstad wrote: > > > > On Sun, May 14, 2017 at 11:59 AM, Monty Taylor > wrote: > >> On 05/11/2017 02:32 PM, Lance Bragstad wrote: >> >>> Hey all, >>> >>> One of the

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 01:09, Lance Bragstad wrote: > > > On Sun, May 14, 2017 at 11:59 AM, Monty Taylor > wrote: > > On 05/11/2017 02:32 PM, Lance Bragstad wrote: > > Hey all, > > One of the Baremetal/VM sessions at the summit focused

Re: [openstack-dev] [nova] [cinder] Follow up on Nova/Cinder summit sessions from an ops perspective

On 5/15/2017 5:34 PM, Matt Riedemann wrote: On 5/15/2017 5:23 PM, Eric Fried wrote: How about aggregates? https://www.youtube.com/watch?v=fu6jdGGdYU4=youtu.be=1784 Aggregates aren't exposed to the user directly, they are exposed to the user via availability zones. Avoiding the explosion of

Re: [openstack-dev] [nova] [cinder] Follow up on Nova/Cinder summit sessions from an ops perspective

On 5/15/2017 5:23 PM, Eric Fried wrote: How about aggregates? https://www.youtube.com/watch?v=fu6jdGGdYU4=youtu.be=1784 Aggregates aren't exposed to the user directly, they are exposed to the user via availability zones. Avoiding the explosion of 1:1 AZs is what we want to avoid for this use

Re: [openstack-dev] [nova] [cinder] Follow up on Nova/Cinder summit sessions from an ops perspective

> If there are alternative ideas on how to design or model this, I'm all > ears. How about aggregates? https://www.youtube.com/watch?v=fu6jdGGdYU4=youtu.be=1784 On 05/15/2017 05:04 PM, Matt Riedemann wrote: > On 5/15/2017 2:28 PM, Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote: >> Hi all, >> >> I'd

[openstack-dev] [infra][all] etcd tarballs for CI use

Folks, In the Boston Summit, there was a session about introducing etcd as a base service[0]. One question that we have to figure out is how to ensure that our CI infra does not depend on tarballs from github. At this moment, though Fedora has 3.1.7 [1], Xenial is way too old, So we will need to

Re: [openstack-dev] [nova] [cinder] Follow up on Nova/Cinder summit sessions from an ops perspective

On 5/15/2017 2:28 PM, Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote: Hi all, I'd like to follow up on a few discussions that took place last week in Boston, specifically in the Compute Instance/Volume Affinity for HPC session

[openstack-dev] [HA] follow-up from HA discussion at Boston Forum

Hi all, Sam P wrote: This is a quick reminder for HA Forum session at Boston Summit. Thank you all for your comments and effort to make this happen in Boston Summit. Time: Thu 11 , 11:00am-11:40am Location: Hynes Convention Center - Level One - MR 103 Etherpad:

Re: [openstack-dev] [oslo][concurrency] lockutils lock fairness / starvation

Excerpts from Ben Nemec's message of 2017-05-15 15:48:33 -0500: > > On 05/15/2017 03:24 PM, Doug Hellmann wrote: > > Excerpts from Legacy, Allain's message of 2017-05-15 19:20:46 +: > >>> -Original Message- > >>> From: Doug Hellmann [mailto:d...@doughellmann.com] > >>> Sent: Monday,

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/14/2017 07:04 AM, Sean Dague wrote: > One of the things that came up in a logging Forum session is how much > effort operators are having to put into reconstructing flows for things > like server boot when they go wrong, as every time we jump a service > barrier the request-id is reset to

Re: [openstack-dev] [oslo][concurrency] lockutils lock fairness / starvation

On 05/15/2017 03:24 PM, Doug Hellmann wrote: Excerpts from Legacy, Allain's message of 2017-05-15 19:20:46 +: -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Monday, May 15, 2017 2:55 PM <...> Excerpts from Legacy, Allain's message of 2017-05-15

Re: [openstack-dev] [oslo][oslo.messaging] Call to deprecate the 'pika' driver in the oslo.messaging project

On 05/15/2017 01:55 PM, Doug Hellmann wrote: Excerpts from Davanum Srinivas (dims)'s message of 2017-05-15 14:27:36 -0400: On Mon, May 15, 2017 at 2:08 PM, Ken Giusti wrote: Folks, It was decided at the oslo.messaging forum at summit that the pika driver will be marked

Re: [openstack-dev] [oslo][concurrency] lockutils lock fairness / starvation

Excerpts from Legacy, Allain's message of 2017-05-15 19:20:46 +: > > -Original Message- > > From: Doug Hellmann [mailto:d...@doughellmann.com] > > Sent: Monday, May 15, 2017 2:55 PM > <...> > > > > Excerpts from Legacy, Allain's message of 2017-05-15 18:35:58 +: > > > import

[openstack-dev] [ironic] this week's priorities and subteam reports

Hi, We are glad to present this week's priorities and subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. This Week's Priorities (as of the weekly ironic meeting) 1. rolling upgrades

[openstack-dev] [os-upstream-institute] Meeting reminder

Hi Training Team, Just a quick reminder that we have our meeting in ten minutes on #openstack-meeting-3. We will mainly focus on retrospectives from the training in Boston a week ago. We have an etherpad with some thoughts already: https://etherpad.openstack.org/p/BOS_OUI_Post_Mortem

[openstack-dev] [oslo][logging] improvements to log debugging ready for review

I have updated the Oslo spec for improving the logging debugging [1] and the patch series that begins the implementation [2]. Please put these on your review priority list. Doug [1] https://review.openstack.org/460112 [2] https://review.openstack.org/#/q/topic:improve-logging-debugging

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 15 May 2017 at 12:12, Doug Hellmann wrote: > Excerpts from Michał Jastrzębski's message of 2017-05-15 10:52:12 -0700: >> For starters, I want to emphasize that fresh set of dockerhub images >> was one of most requested features from Kolla on this summit and few >> other

[openstack-dev] [nova] [cinder] Follow up on Nova/Cinder summit sessions from an ops perspective

Hi all, I'd like to follow up on a few discussions that took place last week in Boston, specifically in the Compute Instance/Volume Affinity for HPC session (https://etherpad.openstack.org/p/BOS-forum-compute-instance-volume-affinity-hpc). In this session, the discussions all trended towards

Re: [openstack-dev] [oslo][concurrency] lockutils lock fairness / starvation

> -Original Message- > From: Doug Hellmann [mailto:d...@doughellmann.com] > Sent: Monday, May 15, 2017 2:55 PM <...> > > Excerpts from Legacy, Allain's message of 2017-05-15 18:35:58 +: > > import eventlet > > eventlet.monkey_patch > > That's not calling monkey_patch -- there are no

Re: [openstack-dev] [vitrage] [nova] VM Heartbeat / Healthcheck Monitoring

Sorry for the slow response. Ifat, You do understand correctly. And I understand, that this does not really fit in Vitrage ... i.e. Vitrage has no other examples of monitoring itself being done in Vitrage. Do you know if Zabbix has VM related monitoring ? If they don’t already do this then, I

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

Excerpts from Michał Jastrzębski's message of 2017-05-15 10:52:12 -0700: > For starters, I want to emphasize that fresh set of dockerhub images > was one of most requested features from Kolla on this summit and few > other features more or less requires readily-available docker > registry.

[openstack-dev] [ironic] Ironic-UI review requirements - single core reviews

All, In our new reality, in order to maximize velocity, I propose that we loosen the review requirements for ironic-ui to allow faster iteration. To this end, I suggest we move ironic-ui to using a single core reviewer for code approval, along the same lines as Horizon[0]. Our new reality is a

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 15 May 2017 at 11:47, Sean Dague wrote: > On 05/15/2017 01:52 PM, Michał Jastrzębski wrote: >> For starters, I want to emphasize that fresh set of dockerhub images >> was one of most requested features from Kolla on this summit and few >> other features more or less requires

Re: [openstack-dev] [oslo][oslo.messaging] Call to deprecate the 'pika' driver in the oslo.messaging project

Excerpts from Davanum Srinivas (dims)'s message of 2017-05-15 14:27:36 -0400: > On Mon, May 15, 2017 at 2:08 PM, Ken Giusti wrote: > > Folks, > > > > It was decided at the oslo.messaging forum at summit that the pika > > driver will be marked as deprecated [1] for removal. > >

Re: [openstack-dev] [oslo][concurrency] lockutils lock fairness / starvation

Excerpts from Legacy, Allain's message of 2017-05-15 18:35:58 +: > Can someone comment on whether the following scenario has been discussed > before or whether this is viewed by the community as a bug? > > While debugging a couple of different issues our investigation has lead > us down the

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 15 May 2017 at 11:19, Davanum Srinivas wrote: > Sorry for the top post, Michal, Can you please clarify a couple of things: > > 1) Can folks install just one or two services for their specific scenario? Yes, that's more of a kolla-ansible feature and require a little bit of

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 05/15/2017 01:52 PM, Michał Jastrzębski wrote: > For starters, I want to emphasize that fresh set of dockerhub images > was one of most requested features from Kolla on this summit and few > other features more or less requires readily-available docker > registry. Features like full release

[openstack-dev] [oslo][concurrency] lockutils lock fairness / starvation

Can someone comment on whether the following scenario has been discussed before or whether this is viewed by the community as a bug? While debugging a couple of different issues our investigation has lead us down the path of needing to look at whether the oslo concurrency lock utilities are

Re: [openstack-dev] [oslo][oslo.messaging] Call to deprecate the 'pika' driver in the oslo.messaging project

On Mon, May 15, 2017 at 2:08 PM, Ken Giusti wrote: > Folks, > > It was decided at the oslo.messaging forum at summit that the pika > driver will be marked as deprecated [1] for removal. [dims} +1 from me. > > The pika driver is another rabbitmq-based driver. It was developed

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

Monty The one missing aspect in this network model, is the ability to identify /categorize a VNF VM, that i.e. Is using SRIOV and only cares about VLAN’s Such VM’s would not have IP Addresses in some cases, and wouldn’t be describable with the external/internal address labels. I feel you need

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

Sorry for the top post, Michal, Can you please clarify a couple of things: 1) Can folks install just one or two services for their specific scenario? 2) Can the container images from kolla be run on bare docker daemon? 3) Can someone take the kolla container images from say dockerhub and use it

Re: [openstack-dev] [neutron] diagnostics

On 5/12/17 12:31 PM, Armando M. wrote: > > Please, do provide feedback in case I omitted some other key takeaway. > > [1] https://etherpad.openstack.org/p/pike-neutron-diagnostics > [2] > http://specs.openstack.org/openstack/neutron-specs/specs/pike/diagnostics.html > Glad you all got a chance

[openstack-dev] [oslo][oslo.messaging] Call to deprecate the 'pika' driver in the oslo.messaging project

Folks, It was decided at the oslo.messaging forum at summit that the pika driver will be marked as deprecated [1] for removal. The pika driver is another rabbitmq-based driver. It was developed as a replacement for the current rabbit driver (rabbit://). The pika driver is based on the 'pika'

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

For starters, I want to emphasize that fresh set of dockerhub images was one of most requested features from Kolla on this summit and few other features more or less requires readily-available docker registry. Features like full release upgrade gates. This will have numerous benefits for users

[openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

Last week at the Forum we had a couple of discussions about collaboration between the various teams building or consuming container images. One topic that came up was deciding how to publish images from the various teams to docker hub or other container registries. While the technical bits seem

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

On 05/15/2017 11:44 AM, Ian Wells wrote: I'm coming to this cold, so apologies when I put my foot in my mouth. But I'm trying to understand what you're actually getting at, here - other than helpful simplicity - and I'm not following the detail of you're thinking, so take this as a form of

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

On 05/15/2017 11:51 AM, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2017-05-15 12:40:17 -0400: On 05/14/2017 01:02 PM, Monty Taylor wrote: ** Bikeshed #1 ** Are "internal" and "external" ok with folks as terms for those two ideas? Yup, ++ from me on the above. ** Bikeshed #2

Re: [openstack-dev] [Heat] Heat template example repository

On 15/05/17 12:10, Steven Hardy wrote: On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote: Hi Steve, I am happy to assist in any way to be honest. It was great to meet you in Boston, and thanks very much for volunteering to help out. BTW one issue I'm aware of is that the

Re: [openstack-dev] [tripleo][logging] oslo.log fluentd native logging

On Wed, May 10, 2017 at 5:41 PM, Dan Prince wrote: > On Mon, 2017-04-24 at 07:47 -0400, Joe Talerico wrote: >> Hey owls - I have been playing with oslo.log fluentd integration[1] >> in >> a poc commit here [2]. Enabling the native service logging is nice >> and >> tracebacks

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

Excerpts from Jay Pipes's message of 2017-05-15 12:40:17 -0400: > On 05/14/2017 01:02 PM, Monty Taylor wrote: > > ** Bikeshed #1 ** > > > > Are "internal" and "external" ok with folks as terms for those two ideas? > > Yup, ++ from me on the above. > > > ** Bikeshed #2 ** > > > > Anybody have a

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

I'm coming to this cold, so apologies when I put my foot in my mouth. But I'm trying to understand what you're actually getting at, here - other than helpful simplicity - and I'm not following the detail of you're thinking, so take this as a form of enquiry. On 14 May 2017 at 10:02, Monty Taylor

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

On 05/14/2017 01:02 PM, Monty Taylor wrote: ** Bikeshed #1 ** Are "internal" and "external" ok with folks as terms for those two ideas? Yup, ++ from me on the above. ** Bikeshed #2 ** Anybody have a problem with the key name "network-models"? They're not network models. They're

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] [heat] [telemetry] - RFC cross project request id tracking

On 05/15/2017 12:16 PM, Doug Hellmann wrote: > Excerpts from Zane Bitter's message of 2017-05-15 11:43:07 -0400: >> On 15/05/17 10:35, Doug Hellmann wrote: >>> Excerpts from Sean Dague's message of 2017-05-15 10:01:20 -0400: On 05/15/2017 09:35 AM, Doug Hellmann wrote: > Excerpts from

Re: [openstack-dev] [tripleo] Validations before upgrades and updates

On Mon, May 08, 2017 at 02:45:08PM +0300, Marios Andreou wrote: >Hi folks, after some discussion locally with colleagues about improving >the upgrades experience, one of the items that came up was pre-upgrade and >update validations. I took an AI to look at the current status of >

Re: [openstack-dev] [releases] Stable branch conflicting information

On Mon, May 15, 2017 at 03:19:09PM +0200, Thierry Carrez wrote: > Sean McGinnis wrote: > > So I noticed today that the release information [0] for Newton appears to > > have > > the wrong date for when Newton transitions to the Legacy Phase. According to > > this conversation [1], I think

Re: [openstack-dev] [Heat] Heat template example repository

Hi Lico and team, Let me show up in this thread again, because I think now is really good timing to introduce myself. My name is Kazunori Shinohara (Kaz) working for NTT Communications as software engineer. I'm taking Heat as public cloud's orchestration services by adding own resource plugins

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] [heat] [telemetry] - RFC cross project request id tracking

Excerpts from Zane Bitter's message of 2017-05-15 11:43:07 -0400: > On 15/05/17 10:35, Doug Hellmann wrote: > > Excerpts from Sean Dague's message of 2017-05-15 10:01:20 -0400: > >> On 05/15/2017 09:35 AM, Doug Hellmann wrote: > >>> Excerpts from Sean Dague's message of 2017-05-14 07:04:03 -0400:

Re: [openstack-dev] [Heat] Heat template example repository

On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote: > Hi Steve, > > I am happy to assist in any way to be honest. > > The backwards compatibility is not always correct as I have seen when > developing our library of templates on Liberty and then trying to deploy it > on Mitaka for

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] [heat] [telemetry] - RFC cross project request id tracking

On 15/05/17 10:35, Doug Hellmann wrote: Excerpts from Sean Dague's message of 2017-05-15 10:01:20 -0400: On 05/15/2017 09:35 AM, Doug Hellmann wrote: Excerpts from Sean Dague's message of 2017-05-14 07:04:03 -0400: One of the things that came up in a logging Forum session is how much effort

[openstack-dev] [nova] notification update week 20

Hi, Here is the status update / focus setting mail about notification work for week 20. Bugs [Medium] https://bugs.launchpad.net/nova/+bug/1657428 The instance notifications are sent with inconsistent timestamp format. The solution is now consits of three patches and the series is wait for

Re: [openstack-dev] [tempest] Jenkins verification failures with stable release gates

On Mon, May 15, 2017 at 2:51 PM Hemanth N wrote: > Hi > > I have written new Tempest functional test cases for Identity OAUTH API. > https://review.openstack.org/#/c/463240/ > > > This patch have dependency on a keystone fix that is still under > review and I have

Re: [openstack-dev] [tripleo] Validations before upgrades and updates

On 05/08/2017 06:45 AM, Marios Andreou wrote: Hi folks, after some discussion locally with colleagues about improving the upgrades experience, one of the items that came up was pre-upgrade and update validations. I took an AI to look at the current status of tripleo-validations [0] and posted

Re: [openstack-dev] [Ironic] Stepping down from core

Hi Lucas, This is a big loss for our community (but lucky OVS/OVN projects!) It has been awesome to work with you over the years. I'll always treasure the friendship we have! I know you're still around but it won't be the same; I'll miss you :-( So long core, and thanks for the fish, although

Re: [openstack-dev] [Heat] Heat template example repository

Hi Steve, I am happy to assist in any way to be honest. The backwards compatibility is not always correct as I have seen when developing our library of templates on Liberty and then trying to deploy it on Mitaka for example. As you guys mentioned in our discussions the Networking example I

[openstack-dev] [neutron][gluon]Gluon project plans

This email is to summarize the contents of several impromptu discussions at the summit last week for those who weren't present. Obviously anything anybody writes is going to include their own perspective, but hopefully I've talked about this in enough detail to enough people that I can do a

Re: [openstack-dev] Suspected SPAM - Re: [vitrage] about  "is_admin" in ctx

Hi Wenjuan, Sorry it took me so long to answer due to the Boston Summit. After making some more checks in order to make it sure, the results are the following: 1. The context that we use has 2 properties regarding admin (is_admin, is_admin_project). 2. The is_admin property

Re: [openstack-dev] [Heat] Heat template example repository

Hi Rico, Great to meet you at the summit. The version related templates I think would work as follows. In each named directory we would have the same set of templates e.g. Single instance Clustered instance resource group etc.. And so if you are on Pike you would go to the pike directory and

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] [heat] [telemetry] - RFC cross project request id tracking

Excerpts from Sean Dague's message of 2017-05-15 10:01:20 -0400: > On 05/15/2017 09:35 AM, Doug Hellmann wrote: > > Excerpts from Sean Dague's message of 2017-05-14 07:04:03 -0400: > >> One of the things that came up in a logging Forum session is how much > >> effort operators are having to put

Re: [openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking

On Sun, May 14, 2017 at 6:02 PM Monty Taylor wrote: > Are "internal" and "external" ok with folks as terms for those two ideas? > Yes, I think so. Slight worry that 'external' is also used in 'router:external' - but I think it will be clear that your proposed context is

Re: [openstack-dev] [Heat] Heat template example repository

On Mon, May 15, 2017 at 03:21:30AM -0400, Lance Haig wrote: >Good to know that there is interest. Thanks for starting this effort - I agree it would be great to see the example templates we provide improved and over time become better references for heat features (as well as being more well

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/15/2017 09:35 AM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2017-05-14 07:04:03 -0400: >> One of the things that came up in a logging Forum session is how much >> effort operators are having to put into reconstructing flows for things >> like server boot when they go

[openstack-dev] [tempest] Jenkins verification failures with stable release gates

Hi I have written new Tempest functional test cases for Identity OAUTH API. https://review.openstack.org/#/c/463240/ This patch have dependency on a keystone fix that is still under review and I have mentioned this patch as Depends-On for above one. (https://review.openstack.org/#/c/464577/)

[openstack-dev] [all] Consolidating web themes

Hi all, I wanted to make you all aware of some consolidation efforts I'll be working on this release. You may have noticed a new logo for OpenStack, and perhaps you saw the update to the web design and headers on docs.openstack.org as well. To continue these efforts, I'll also be working on

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

Excerpts from Sean Dague's message of 2017-05-14 07:04:03 -0400: > One of the things that came up in a logging Forum session is how much > effort operators are having to put into reconstructing flows for things > like server boot when they go wrong, as every time we jump a service > barrier the

Re: [openstack-dev] [releases] Stable branch conflicting information

Sean McGinnis wrote: > So I noticed today that the release information [0] for Newton appears to have > the wrong date for when Newton transitions to the Legacy Phase. According to > this conversation [1], I think (thought?) we established that rolling over to > each support phase would stay on a

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On Sun, May 14, 2017 at 11:59 AM, Monty Taylor wrote: > On 05/11/2017 02:32 PM, Lance Bragstad wrote: > >> Hey all, >> >> One of the Baremetal/VM sessions at the summit focused on what we need >> to do to make OpenStack more consumable for application developers [0]. >> As

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/15/2017 08:16 AM, Lance Bragstad wrote: > > > On Mon, May 15, 2017 at 6:20 AM, Sean Dague > wrote: > > On 05/15/2017 05:59 AM, Andrey Volkov wrote: > > > >> The last time this came up, some people were concerned that trusting > >>

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On Mon, May 15, 2017 at 6:20 AM, Sean Dague wrote: > On 05/15/2017 05:59 AM, Andrey Volkov wrote: > > > >> The last time this came up, some people were concerned that trusting > >> request-id on the wire was concerning to them because it's coming from > >> random users. > > > >

Re: [openstack-dev] [FaaS] Introduce a FaaS project

Hi, I am very interested in FaaS coming to OpenStack, it totally makes sense to have it as part of the platform. I have observed the current OpenStack Picasso project although I too am concerned about vendor lock in to IronFunctions with the Picasso project. I think it is also important not to

[openstack-dev] [tc] revised Postgresql deprecation patch for governance

We had a forum session in Boston on Postgresql and out of that agreed to the following steps forward: 1. explicitly warn in operator facing documentation that Postgresql is less supported than MySQL. This was deemed better than just removing documentation, because when people see Postgresql files

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

On 05/15/2017 05:59 AM, Andrey Volkov wrote: > >> The last time this came up, some people were concerned that trusting >> request-id on the wire was concerning to them because it's coming from >> random users. > > TBH I don't see the reason why a validated request-id value can't be > logged on

Re: [openstack-dev] [Heat] Heat template example repository

Hi Lance and all others who shows interest IMO, after some feedback from the summit. I think it will be greate to have efforts on - *bug/blueprint: We needs more people doing fix/review/spec. Since we still on the way to make heat more handy as Orchestration tools* - *template

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

> The last time this came up, some people were concerned that trusting > request-id on the wire was concerning to them because it's coming from > random users. TBH I don't see the reason why a validated request-id value can't be logged on a callee service side, probably because I missed some

Re: [openstack-dev] [FaaS] Introduce a FaaS project

On Mon, May 15, 2017 at 8:32 PM, Sam P wrote: > Hi Larry, > Thank you for the details. > I am interested and like the idea of no vendor/platform lock-in. > > However, I still have this stupid question in me. > Why FaaS need to be in the OpenStack ecosystem? Can it

Re: [openstack-dev] [FaaS] Introduce a FaaS project

On Mon, May 15, 2017 at 5:59 PM, Li Ma wrote: > Do you have submitted a proposal to create this project under > OpenStack umbrella? > Yeah, as the first step: https://review.openstack.org/#/c/463953/ Cheers, Lingxian Kong (Larry)

Re: [openstack-dev] [FaaS] Introduce a FaaS project

Hi Larry, Thank you for the details. I am interested and like the idea of no vendor/platform lock-in. However, I still have this stupid question in me. Why FaaS need to be in the OpenStack ecosystem? Can it survive outside and still be able to integrate with OpenStack? This FaaS must able

Re: [openstack-dev] [Heat] Heat template example repository

Good to know that there is interest. I was thinking that we should perhaps create a directory for each openstack version. so we start say with a mitaka directory and then move the files there and test them all so that they work with Liberty. Then we can copy it over to Mitaka and do the same but

Re: [openstack-dev] [tripleo][ui] another i18n proposal for heat templates 'description' help strings

On Wed, 2017-05-10 at 14:05 +0200, Jiri Tomasek wrote: > I am probably a bit late to the discussion, but I think we're > missing  > quite important thing and that is the fact that TripleO UI is > supposed  > to use various plans (template sets) not strictly tripleo-heat- > templates  > repository

Re: [openstack-dev] [FaaS] Introduce a FaaS project

That's interesting. Serverless is a general computing engine that can brings lots of possibility of how to make use of resource managed by OpenStack. I'd like to see a purely OpenStack-powered solution there. Do you have submitted a proposal to create this project under OpenStack umbrella? On