[openstack-dev] [all][infra] Zuul v3 migration update

Hey everybody, We're there. It's ready. We've worked through all of the migration script issues and are happy with the results. The cutover trigger is primed and ready to go. But as it's 21:51 UTC / 16:52 US Central it's a short day to be available to respond to the questions folks may have.

[openstack-dev] [all][infra] Zuul v3 migration update

Hey everybody, We got significantly further along with our Zuul v3 rollout today. We uncovered some fun bugs in the migration but were able to fix most of them rather quickly. We've pretty much run out of daylight though for the majority of the team and there is a tricky zuul-cloner related

Re: [openstack-dev] Update on Zuul v3 Rollout plans for PTG week

tl;dr - We didn't roll v3 out at the PTG, current plan is 2017-09-25. On 09/09/2017 08:55 AM, Monty Taylor wrote: Heya everybody! You may or may not be aware that we've been targeting a go-live for Zuul v3 for Monday of the PTG. After our status meeting on the topic this afterno

[openstack-dev] Update on Zuul v3 Rollout plans for PTG week

Heya everybody! You may or may not be aware that we've been targeting a go-live for Zuul v3 for Monday of the PTG. After our status meeting on the topic this afternoon we have decided to hold-off and do a bit more work on the migration itself while we're in Denver together. Zuul v3 itself is

[openstack-dev] [tc] Declaring explicit minimum database versions

Hey all, Morgan was stabbing himself in the eyes yesterday dealing with a database issue in keystone related to datetimes and subsecond precision. As usually happens when people want to stab MySQL I got roped in and my first thought was "dude, we landed the subsecond precision patches in Driz

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

On 08/07/2017 11:55 AM, Boden Russell wrote: On 8/4/17 1:26 PM, Boris Pavlovic wrote: That's not going to work for dozens of OpenStack projects. It's just won't scale. Every project should maintain plugin for their project. And it should be enough to say "pip install python-client" that extend

[openstack-dev] [elections][shade] PTL candidacy for Queens

I would like to be the PTL of the shade project for another cycle. Over the past few years the shade project has grown from a utility library containing some logic needed by the Infrastructure team and Ansible for interacting with OpenStack clouds to a rich SDK that serves the general needs of

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

On 08/04/2017 04:03 PM, Dean Troyer wrote: On Fri, Aug 4, 2017 at 11:52 AM, Monty Taylor wrote: [...] * Both shade and python-openstackclient have investigated using openstacksdk as their REST layer but were unable to because it puts some abstractions in layers that make it impossible to do

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

On 08/04/2017 03:24 AM, Thierry Carrez wrote: Michael Johnson wrote: I was wondering what is the current status of the python-openstacksdk project. The Octavia team has posted some patches implementing our new Octavia v2 API [1] in the SDK, but we have not had any reviews. I have also asked so

[openstack-dev] [release][requirements][shade][infra] FFE for zuul-sphinx

Heya, We'd like to request a requirements feature freeze exception to add the zuul-sphinx library. zuul-sphinx is an Infra-managed Sphinx extension used to process job documentation for zuul jobs for Zuul v3. Since jobs can be defined in individual project repos in Zuul v3, generating docume

[openstack-dev] [all] Rollout of Zuul v3 at the PTG

Hey everybody! The time has come at long last, we're actually aiming at a concrete date for rolling Zuul v3 live. \o/ tl;dr - Assuming things go well we want to do it at the PTG We couldn't be more excited - there are a giant pile of feature requests from folks that we've been responding wit

Re: [openstack-dev] [TripleO][keystone] internal endpoints vs sanity

On 07/24/2017 04:23 PM, Attila Fazekas wrote: Thanks for your answer. The real question is do we agree in the internalULR usage what suggested in [1] is a bad security practice and should not be told to operators at all. Also we should try to get rid off the enpointTypes in keystone v4. Do we

Re: [openstack-dev] [oslo.db] [ndb] ndb namespace throughout openstack projects

On 07/24/2017 08:05 AM, Michael Bayer wrote: On Sun, Jul 23, 2017 at 6:10 PM, Jay Pipes wrote: Glad you brought this up, Mike. I was going to start a thread about this. Comments inline. On 07/23/2017 05:02 PM, Michael Bayer wrote: Well, besides that point (which I agree with), that is attempti

Re: [openstack-dev] [keystone] keystoneauth1 3.0.0 broken keystonemiddleware

On 07/22/2017 07:14 AM, Lance Bragstad wrote: After a little head scratching and a Pantera playlist later, we ended up figuring out the main causes. The failures can be found in the gate [0]. The two failures are detailed below: 1.) Keystoneauth version 3.0.0 added a lot of functionality and mig

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 07/19/2017 12:11 AM, Zane Bitter wrote: On 17/07/17 23:12, Lance Bragstad wrote: Would Keystone folks be happy to allow persistent credentials once we have a way to hand out only the minimum required privileges? If I'm understanding correctly, this would make application credential

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 07/19/2017 12:18 AM, Zane Bitter wrote: On 18/07/17 10:55, Lance Bragstad wrote: Would Keystone folks be happy to allow persistent credentials once we have a way to hand out only the minimum required privileges? If I'm understanding correctly, this would make application credentia

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

On 07/12/2017 02:02 AM, Flavio Percoco wrote: On 11/07/17 19:21 -0500, Monty Taylor wrote: On 07/11/2017 06:47 AM, Flavio Percoco wrote: On 11/07/17 14:20 +0300, Mikhail Fedosin wrote: On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor wrote: On 07/10/2017 04:31 PM, Mikhail Fedosin wrote: Third

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

On 07/13/2017 08:42 AM, Erno Kuvaja wrote: On Wed, Jul 12, 2017 at 1:21 AM, Monty Taylor wrote: On 07/11/2017 06:47 AM, Flavio Percoco wrote: On 11/07/17 14:20 +0300, Mikhail Fedosin wrote: On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor wrote: On 07/10/2017 04:31 PM, Mikhail Fedosin

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

On 07/11/2017 06:47 AM, Flavio Percoco wrote: On 11/07/17 14:20 +0300, Mikhail Fedosin wrote: On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor wrote: On 07/10/2017 04:31 PM, Mikhail Fedosin wrote: Third, all these changes can be hidden in Glare client. So if we try a little, we can achieve

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

On 07/10/2017 04:31 PM, Mikhail Fedosin wrote: Thank you for asking this! It's really very important and interesting, so I'm going to explain those things more detailed. First, when we designed Glare, we kept in mind the compatibility with Glance, and I can tell that Glance data from the datab

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

On 07/10/2017 04:31 PM, Monty Taylor wrote: On 07/10/2017 01:21 PM, Ed Leafe wrote: On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin <mailto:mfedo...@gmail.com>> wrote: Given all the advantages and features of Glare, I believe that it can become the successful drop-in replacement.

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

On 07/10/2017 01:21 PM, Ed Leafe wrote: On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin > wrote: Given all the advantages and features of Glare, I believe that it can become the successful drop-in replacement. Can you clarify this? Let’s assume I have a decent-sized de

Re: [openstack-dev] [docs] [pbr] [ptl] [oslo] Removing pbr's custom 'build_sphinx' setuptools command

On 07/07/2017 12:12 PM, Jeremy Stanley wrote: On 2017-07-07 11:20:30 -0400 (-0400), Doug Hellmann wrote: [...] We also discussed changing the CI interface to build docs to use the "tox -e docs" command like contributors generally run locally. [...] Better still, something like `tox -e venv --

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Thierry Carrez <mailto:thie...@openstack.org> June 29, 2017 at

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

On 06/29/2017 03:00 AM, Thierry Carrez wrote: Monty Taylor wrote: On 06/28/2017 09:50 AM, Thierry Carrez wrote: [...] Removing the root cause would be a more radical move: stop offering hosting to non-OpenStack projects on OpenStack infrastructure altogether. We originally did that for a

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

On 06/28/2017 11:27 PM, Steven Dake wrote: On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor <mailto:mord...@inaugust.com>> wrote: On 06/28/2017 09:50 AM, Thierry Carrez wrote: Hi everyone, Two weeks ago, as a result of a discussion at the Board+TC+UC

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

On 06/29/2017 02:35 AM, Thierry Carrez wrote: Sean McGinnis wrote: The central issue being discussed here is an issue of external perception. It's hard for newcomers to the OpenStack world to see what is a part of OpenStack and what's not. If you google "openstack machine learning", the first h

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

On 06/28/2017 09:50 AM, Thierry Carrez wrote: Hi everyone, Two weeks ago, as a result of a discussion at the Board+TC+UC workgroup working on "better communicating what is openstack", I started a thread[1] about moving away from big tent terminology. The thread went in a lot of directions, inclu

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

On 06/28/2017 01:48 PM, Clay Gerrard wrote: On Wed, Jun 28, 2017 at 7:50 AM, Thierry Carrez > wrote: 2- it lets us host things that are not openstack but which we work on (like abandoned Python libraries or GPL-licensed things) in a familiar environm

Re: [openstack-dev] [ironic][nova] Goodbye^W See you later

On 06/08/2017 07:45 AM, Jim Rollenhagen wrote: Hey friends, I've been mostly missing for the past six weeks while looking for a new job, so maybe you've forgotten me already, maybe not. I'm happy to tell you I've found one that I think is a great opportunity for me. But, I'm sad to tell you t

[openstack-dev] [tc][ptls][all] Potential Queens Goal: Implement collection link OR full discovery alignment

Hey everybody! I have submitted two potential goals for Queens: https://review.openstack.org/#/c/468436 - add collection links https://review.openstack.org/#/c/468437 - full discovery alignment One is a subset of the other, so the decision is two-fold * do we do this at all? * do we do the sma

Re: [openstack-dev] Changing project schemas in patches; upgrade implications

On 05/31/2017 08:51 AM, Amrith Kumar wrote: This email thread relates to[1], a change that aims to improve cross-SQL support in project schemas. I want to explicitly exclude the notion of getting rid of support for PostgreSQL in the underlying project schemas, a topic that was discussed at th

Re: [openstack-dev] [requirements] Do we care about pypy for clients (broken by cryptography)

On 05/31/2017 06:39 AM, Sean McGinnis wrote: On Wed, May 31, 2017 at 06:37:02AM -0500, Sean McGinnis wrote: We had a discussion a few months back around what to do for cryptography since pycrypto is basically dead [1]. After some discussion, at least on the Cinder project, we decided the best wa

Re: [openstack-dev] [ironic] using keystone right - catalog, endpoints, tokens and noauth

On 05/24/2017 12:51 PM, Eric Fried wrote: Pavlo- There's a blueprint [1] whereby we're trying to address a bunch of these same concerns in nova. You can see the first part in action here [2]. However, it has become clear that nova is just one of the many services that would benefit fro

Re: [openstack-dev] Documenting config drive - what do you want to see?

On 05/24/2017 10:07 AM, Clark Boylan wrote: On Wed, May 24, 2017, at 07:39 AM, Matt Riedemann wrote: Rocky tipped me off to a request to document config drive which came up at the Boston Forum, and I tracked that down to Clark's wishlist etherpad [1] (L195) which states: "Document the config

Re: [openstack-dev] Save the Date- Queens PTG

On 05/23/2017 06:27 PM, Anita Kuno wrote: On 2017-05-23 07:25 PM, Anita Kuno wrote: On 2017-04-05 06:05 PM, Erin Disney wrote: We are excited to announce the September Project Teams Gathering in Denver, CO at the Denver Renaissance Stapleton Hotel this September 11th-15th. As mentioned at the

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/19/2017 05:10 PM, Matt Riedemann wrote: On 5/19/2017 3:35 PM, Monty Taylor wrote: Heck - while I'm on floating ips ... if you have some pre-existing floating ips and you want to boot servers on them and you want to do that in parallel, you can't. You can boot a server with a f

Re: [openstack-dev] [tc] revised Postgresql support status patch for governance

On 05/18/2017 02:49 PM, Sean Dague wrote: On 05/18/2017 01:02 PM, Mike Bayer wrote: On 05/17/2017 02:38 PM, Sean Dague wrote: Some of the concerns/feedback has been "please describe things that are harder by this being an abstraction", so examples are provided. so let's go through this lis

[openstack-dev] [tc] Active or passive role with our database layer

Hi all! As the discussion around PostgreSQL has progressed, it has come clear to me that there is a decently deep philosophical question on which we do not currently share either definition or agreement. I believe that the lack of clarity on this point is one of the things that makes the Post

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/19/2017 04:27 PM, Matt Riedemann wrote: On 5/19/2017 3:03 PM, Monty Taylor wrote: On 05/19/2017 01:04 PM, Sean Dague wrote: On 05/19/2017 01:38 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 11:53 AM, Chris Friesen wrote: ..., but it seems to me that the logical extension of that is

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/19/2017 03:13 PM, Monty Taylor wrote: On 05/19/2017 01:53 PM, Sean Dague wrote: On 05/19/2017 02:34 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote: These should be used as ways to experiment with the kinds of interfaces we want cheaply, then take them back

Re: [openstack-dev] [neutron][heat] - making Neutron more friendly for orchestration

On 05/19/2017 04:03 PM, Kevin Benton wrote: I split this conversation off of the "Is the pendulum swinging on PaaS layers?" thread [1] to discuss some improvements we can make to Neutron to make orchestration easier. There are some pain points that heat has when working with the Neutron API. I w

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/19/2017 03:05 PM, Zane Bitter wrote: On 19/05/17 15:06, Kevin Benton wrote: Don't even get me started on Neutron.[2] It seems to me the conclusion to that thread was that the majority of your issues stemmed from the fact that we had poor documentation at the time. A major component of t

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/19/2017 01:53 PM, Sean Dague wrote: On 05/19/2017 02:34 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote: These should be used as ways to experiment with the kinds of interfaces we want cheaply, then take them back into services (which is a more expensive process

Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

On 05/19/2017 01:04 PM, Sean Dague wrote: On 05/19/2017 01:38 PM, Dean Troyer wrote: On Fri, May 19, 2017 at 11:53 AM, Chris Friesen wrote: ..., but it seems to me that the logical extension of that is to expose simple orthogonal APIs where the nova boot request should only take neutron port i

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On 05/17/2017 10:14 AM, Joe Topjian wrote: On Tue, May 16, 2017 at 4:13 PM, Monty Taylor mailto:mord...@inaugust.com>> wrote: Hey all! I read the API docs A LOT. (thank you to all of you who have worked on writing them) As I do, a gotcha I hit up against a non-zero amo

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

On 05/18/2017 04:32 PM, Zane Bitter wrote: On 18/05/17 07:53, Sean Dague wrote: My worry about policy also is that I'm not sure how safe it is for a project owned API key to inherit permissions from the user who created it. I can't think of a better way to it though but I'm still slightly unco

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

On 05/18/2017 06:53 AM, Sean Dague wrote: On 05/17/2017 09:34 PM, Adrian Turjak wrote: On 17/05/17 23:20, Sean Dague wrote: On 05/16/2017 07:34 PM, Adrian Turjak wrote: Anyway that aside, I'm sold on API keys as a concept in this case provided they are project owned rather than user owned,

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

On 05/16/2017 02:44 PM, Sean Dague wrote: On 05/16/2017 03:40 PM, Monty Taylor wrote: On 05/16/2017 10:20 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100: On Tue, 16 May 2017, Monty Taylor wrote: FWIW - I'm un-crazy about the term API Key

[openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

Hey all! I read the API docs A LOT. (thank you to all of you who have worked on writing them) As I do, a gotcha I hit up against a non-zero amount is mapping the descriptions of the response parameters to the form of the response itself. Most of the time there is a top level parameter under

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

On 05/16/2017 10:20 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100: On Tue, 16 May 2017, Monty Taylor wrote: FWIW - I'm un-crazy about the term API Key - but I'm gonna just roll with that until someone has a better idea. I'm uncr

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

On 05/16/2017 05:39 AM, Sean Dague wrote: On 05/15/2017 10:00 PM, Adrian Turjak wrote: On 16/05/17 13:29, Lance Bragstad wrote: On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak mailto:adri...@catalyst.net.nz>> wrote: Based on the specs that are currently up in Keystone-specs, I wou

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

so take this as a form of enquiry. Thanks for diving in - no foot-mouth worries here. It's a hard topic. On 14 May 2017 at 10:02, Monty Taylor mailto:mord...@inaugust.com>> wrote: First off, we need to define two terms: "external" - an address that can be used f

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 th

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

Hey all! LONG EMAIL WARNING I'm working on a proposal to formalize a cloud profile document. (we keep and support these in os-client-config, but it's grown up ad-hoc and is hard for other languages to consume -so we're going to rev it and try to encode information in it more sanely) I need he

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

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 group we recognized the need for application specific passwords or API keys and nearly everyo

Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

On 05/05/2017 11:52 AM, Dean Troyer wrote: On Fri, May 5, 2017 at 11:36 AM, Alex Schultz wrote: configuration and usability issues. But those aren't exciting so people don't want to work on them... [Not picking on Alex here, but I've seen this repeated again in this thread like every other on

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

On 05/04/2017 06:58 AM, Sean Dague wrote: On 05/03/2017 11:56 PM, Monty Taylor wrote: On 05/03/2017 03:47 AM, Thierry Carrez wrote: Monty Taylor wrote: On 05/01/2017 10:44 AM, Ben Swartzlander wrote: On 04/28/2017 06:26 PM, Monty Taylor wrote: [...] Thoughts? Anyone violently opposed? I

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

On 05/03/2017 03:47 AM, Thierry Carrez wrote: Monty Taylor wrote: On 05/01/2017 10:44 AM, Ben Swartzlander wrote: On 04/28/2017 06:26 PM, Monty Taylor wrote: [...] Thoughts? Anyone violently opposed? I don't have any problems with this idea. My main concern would be for back

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

On 05/02/2017 11:49 AM, Sean McGinnis wrote: On Tue, May 02, 2017 at 03:36:20PM +0200, Jordan Pittier wrote: On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann wrote: In Cinder, there are many features/APIs which are backend specific and will return 405 or 501 if same is not implemented on any ba

Re: [openstack-dev] [devstack] [all] systemd in devstack by default

On 05/03/2017 06:45 PM, James Slagle wrote: On Tue, May 2, 2017 at 9:19 AM, Monty Taylor wrote: I absolutely cannot believe I'm saying this given what the change implements and my general steaming hatred associated with it ... but this is awesome work and a definite improvement over

Re: [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

On 05/02/2017 12:11 AM, Adrian Turjak wrote: Hello OpenStack folks, As part of my dev work I recently put together a cool little tool which lets me have much easier access to the various OpenStack python clients in the scope of a python interpreter session. The first version was a little rough a

Re: [openstack-dev] [devstack] [all] systemd in devstack by default

On 05/02/2017 08:30 AM, Sean Dague wrote: We started running systemd for devstack in the gate yesterday, so far so good. The following patch (which will hopefully land soon), will convert the default local use of devstack to systemd as well - https://review.openstack.org/#/c/461716/. It also inc

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

On 05/01/2017 10:44 AM, Ben Swartzlander wrote: On 04/28/2017 06:26 PM, Monty Taylor wrote: Hey everybody! Yay! (I'm sure you're all saying this, given the topic. I'll let you collect yourself from your exuberant celebration) == Background == As I'm sure you all know,

Re: [openstack-dev] [Openstack] All Hail our Newest Release Name - OpenStack Rocky

I, for one, welcome our new "Rocky" overlord project name :) Cheers, --Morgan On Fri, Apr 28, 2017 at 2:54 PM, Monty Taylor mailto:mord...@inaugust.com>> wrote: > Hey everybody! > > There isn't a ton more to say past the subject. The

[openstack-dev] [all][tc] let's bikeshed like crazy over in service-types-authority

Hey everybody, I just went ahead and made a patch filling in all of the OpenStack projects: https://review.openstack.org/#/c/461221/ There are naming guidelines in the service-types-authority, so where things didn't match, I have proposed new names. I don't necessarily think those new names

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

that repo, although ideal, was lacking. ++ totally agree. On 29 Apr. 2017 10:26 am, Monty Taylor wrote: Hey everybody! Yay! (I'm sure you're all saying this, given the topic. I'll let you collect yourself from your exuberant celebration) == Background == As

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

26 PM, Monty Taylor wrote: Hey everybody! Yay! (I'm sure you're all saying this, given the topic. I'll let you collect yourself from your exuberant celebration) == Background == As I'm sure you all know, we've been trying to make some hearway for a while on getting service-ty

[openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

Hey everybody! Yay! (I'm sure you're all saying this, given the topic. I'll let you collect yourself from your exuberant celebration) == Background == As I'm sure you all know, we've been trying to make some hearway for a while on getting service-types that are registered in the keystone se

[openstack-dev] All Hail our Newest Release Name - OpenStack Rocky

Hey everybody! There isn't a ton more to say past the subject. The "R" release of OpenStack shall henceforth be known as "Rocky". I believe it's the first time we've managed to name a release after a community member - so please everyone buy RockyG a drink if you see her in Boston. For tho

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

lance URL for purposes of fail over. Thanks, Mike On 4/28/17, 8:20 AM, "Monty Taylor" wrote: Thank you both for your feedback - that's really helpful. Let me say a few more words about what we're trying to accomplish here overall so that maybe we can figu

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

Well, endpoint_overrride itself is already a concept with keystoneauth and all of the various client libraries (and more generally is already a concept in consuming the API services) It's a singleton - so we'd need to add a concept of an endpoint_override_list (*handwave on name*) Oh - oops -

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

Thank you both for your feedback - that's really helpful. Let me say a few more words about what we're trying to accomplish here overall so that maybe we can figure out what the right way forward is. (it may be keeping the glance api servers setting, but let me at least make the case real quic

Re: [openstack-dev] [Openstack][Neutron]Why we use secuirity group which only support dispatching whiltelist rules?

On 04/25/2017 10:32 AM, Gary Kotton wrote: Hi, I would like us to think of considering enabling an API that would allow ‘deny’, for example an admin could overwrite a tenant’s security groups. For example, and admin may not want a specific source range to access the tenants VM’s. The guys work

[openstack-dev] [requirements][all][keystone] Getting requests from keystoneauth not directly

Hey everybody! I just put up a couple of patches here: https://review.openstack.org/#/q/topic:ksa-requests that remove direct depends from client libs on requests, which leave them to rely on keystoneauth for their requests dependency. The reason I pushed these up is that we're seeing bug re

Re: [openstack-dev] [all][ptls][tc] help needed filling out project-navigator data

unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> Monty Taylor <mailto:mord...@inaugust.com> April 18, 2017 at 3:03 PM Hey everybody! The Foundation is rolling out

[openstack-dev] OpenStack "R" Release Naming Preliminary Results

Hello all! We left the voting open for an additional week because of how long it took to get emails sent out and the subsequent email issues. We'll be looking at options for next time to make that better. The raw results are below - however... **PLEASE REMEMBER** that these now have to go th

Re: [openstack-dev] [tc] version document for project navigator

pprove it now and ask for forgiveness later :) Monty Taylor <mailto:mord...@inaugust.com> April 13, 2017 at 10:25 AM On 04/13/2017 08:28 AM, Jimmy McArthur wrote: Just checking on the progress of this. :) Unfortunately a good portion of the TC was away this week at the leadership training so

[openstack-dev] [all][ptls][tc] help needed filling out project-navigator data

Hey everybody! The Foundation is rolling out a new version of the Project Navigator. One of the things it contains is a section that shows API versions available for each project for each release. They asked the TC's help in providing that data, so we spun up a new repository: http://git.o

Re: [openstack-dev] [tc] version document for project navigator

like though, so I'm mostly expecting that to be what we end up with. We should be able to get final approval by Tuesday, and then can work on getting all of the project info filled in. Monty Taylor <mailto:mord...@inaugust.com> April 7, 2017 at 7:05 AM There is a new

Re: [openstack-dev] [shade] help wanted - tons to do, not enough people

On 04/12/2017 01:15 PM, Sean Dague wrote: On 04/12/2017 01:38 PM, Monty Taylor wrote: On 04/12/2017 11:21 AM, Joshua Harlow wrote: Just a question, not meant as anything bad against shade, But would effort be better spent on openstacksdk? tl;dr - great in practice, falls apart in the

Re: [openstack-dev] [shade] help wanted - tons to do, not enough people

and legit question - but as of right now I don't think it would actually make anyone's lives better. Thoughts? Monty Taylor wrote: Hey everybody! This isn't the most normal thing I've done, but whatever. We've got this great library, shade, which people love to use to i

[openstack-dev] [shade] help wanted - tons to do, not enough people

Hey everybody! This isn't the most normal thing I've done, but whatever. We've got this great library, shade, which people love to use to interact with their OpenStack clouds (even when they don't know they're using it, like when they're using Ansible) - and which we use in Infra behind nodep

[openstack-dev] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core

Hey all, As I'm sure you all know, pbr is both our most pervasively used dependency and our least well understood. Nobody ever wants to look at the code (sorry, I can write ugly code sometimes - but also wow setuptools) or dig in to figure out what happened when things break. Recently Stephe

Re: [openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

On 04/06/2017 07:34 AM, Monty Taylor wrote: Hey all! I've started the R Release Name poll and currently am submitting everyone's email address to the system. In order to not make our fine friends at Carnegie Mellon (the folks who run the CIVS voting service) upset, I have a script th

Re: [openstack-dev] [tc] [elections] Available time and top priority

On 04/10/2017 04:41 PM, Chris Dent wrote: On Mon, 10 Apr 2017, Matt Riedemann wrote: This might also tie back in with what cdent was mentioning, and if the flurry of conversation during a TC meeting throws people off, maybe the minutes should be digested after the meeting in the mailing list. I

Re: [openstack-dev] [tc] project-navigator-data repo live - two choices need input

aveat is that we still to add from our side, Release and Component data, but i guess that is doable thx u so much !!! i will take a look to both formats cheers 2017-04-11 8:44 GMT-03:00 Monty Taylor mailto:mord...@inaugust.com>>: Hey all, We've got the project-navigator-da

[openstack-dev] [tc] project-navigator-data repo live - two choices need input

Hey all, We've got the project-navigator-data repo created and there are two proposals up for what the content should look like. Could TC folks please add openstack/project-navigator-data to your watch lists, and go review: https://review.openstack.org/#/c/454688 https://review.openstack.or

Re: [openstack-dev] [tc] [elections] Available time and top priority

On 04/10/2017 01:52 PM, Matt Riedemann wrote: On 4/10/2017 1:18 PM, Chris Dent wrote: On Mon, 10 Apr 2017, Thierry Carrez wrote: So my question is the following: if elected, how much time do you think you'll be able to dedicate to Technical Committee affairs (reviewing proposed changes and pus

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 04/10/2017 10:23 AM, Akihiro Motoki wrote: 2017-04-10 23:19 GMT+09:00 Dean Troyer : On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users still use API 2.36 for network management and newer API versions

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 04/10/2017 10:24 AM, Sean Dague wrote: On 04/10/2017 11:19 AM, Matt Riedemann wrote: On 4/10/2017 9:19 AM, Dean Troyer wrote: On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users still use API 2.36 fo

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 04/10/2017 10:37 AM, Monty Taylor wrote: On 04/10/2017 09:19 AM, Dean Troyer wrote: On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users still use API 2.36 for network management and newer API

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 04/10/2017 09:19 AM, Dean Troyer wrote: On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users still use API 2.36 for network management and newer API versions for other compute operation. This is proba

Re: [openstack-dev] [tc] version document for project navigator

On 04/06/2017 03:51 PM, Jimmy McArthur wrote: Cool. Thanks Monty! Monty Taylor <mailto:mord...@inaugust.com> April 6, 2017 at 3:21 PM On 04/06/2017 11:58 AM, Jimmy McArthur wrote: Assuming this format is accepted, do you all have any sense of when this data will be complete for all pr

Re: [openstack-dev] [tc] version document for project navigator

go to to propose fixes to the project navigator data. Not knowing how to fix that data is a common complaint, so if we can point people to a git repo (and redirect people from there to the places where other bits of information happen to live) that would be great. Monty Taylor <mailto:mord...@inau

[openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

Hey all! I've started the R Release Name poll and currently am submitting everyone's email address to the system. In order to not make our fine friends at Carnegie Mellon (the folks who run the CIVS voting service) upset, I have a script that submits the emails one at a time with a half-secon

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

The tone of this in inappropriate and not in keeping with our community code of conduct: https://www.openstack.org/legal/community-code-of-conduct/ It is neither friendly, patient, welcoming, considerate or respectful. No attempt has been made to collaborate openly on a solution, or to unders

Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

point. Yes! Very well said. UUID is the excellent choice for API - auto-inc is the excellent choice for the database. 2017-04-05 22:00 GMT+09:00 Monty Taylor : On 02/21/2017 07:28 AM, gordon chung wrote: On 21/02/17 01:28 AM, Qiming Teng wrote: in mysql[2]. Can someone remind me the

Re: [openstack-dev] [Zun]Use 'uuid' instead of 'id' as object ident in data model

On 02/21/2017 07:28 AM, gordon chung wrote: On 21/02/17 01:28 AM, Qiming Teng wrote: in mysql[2]. Can someone remind me the benefits we get from Integer over UUID as primary key? UUID, as its name implies, is meant to be an identifier for a resource. Why are we generating integer key values?

[openstack-dev] [tc] version document for project navigator

Hey all, As per our discussion in today's TC meeting, I have made a document format for reporting versions to the project navigator. I stuck it in the releases repo: https://review.openstack.org/453361 Because there was already per-release information there, and the governance repo did no

<    1   2   3   4   5   6   7   8   9   >