Re: [openstack-dev] Proposal for a process to keep up with Python releases

On 26/10/18 5:09 AM, Thomas Goirand wrote: On 10/22/18 9:12 PM, Zane Bitter wrote: On 22/10/18 10:33 AM, Thomas Goirand wrote: This can only happen if we have supporting distribution packages for it. IMO, this is a call for using Debian Testing or even Sid in the gate. It depends on which

Re: [openstack-dev] Proposal for a process to keep up with Python releases

On 25/10/18 1:38 PM, William M Edmonds wrote: Zane Bitter wrote on 10/22/2018 03:12:46 PM: > On 22/10/18 10:33 AM, Thomas Goirand wrote: > > On 10/19/18 5:17 PM, Zane Bitter wrote: > >> Integration Tests > >> - > >> > >> In

Re: [openstack-dev] Proposal for a process to keep up with Python releases

There seems to be agreement that this is broadly a good direction to pursue, so I proposed a TC resolution. Let's shift discussion to the review: https://review.openstack.org/613145 cheers, Zane. On 19/10/18 11:17 AM, Zane Bitter wrote: There hasn't been a Python 2 release in 8 years

[openstack-dev] [karbor][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Karbor team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [monasca][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Monasca team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [searchlight][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Searchlight team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [barbican][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Barbican team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [glance][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Glance team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [keystone][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Keystone team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [cinder][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Cinder team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [manila][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Manila team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [swift][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Swift team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help guide

[openstack-dev] [cyborg][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Cyborg team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [ironic][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Ironic team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [designate][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Designate team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [octavia][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Octavia team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [neutron][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Neutron team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [qinling][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Qinling team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [nova][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Nova team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help guide

[openstack-dev] [zun][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Zun team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help guide

[openstack-dev] [zaqar][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Zaqar team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help guide

[openstack-dev] [blazar][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Blazar team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [senlin][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Senlin team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [heat][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Heat team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help guide

[openstack-dev] [telemetry][aodh][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Telemetry team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [mistral][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Mistral team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [masakari][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Masakari team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [solum][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Solum team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help guide

[openstack-dev] [freezer][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Freezer team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [murano][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Murano team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [sahara][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Sahara team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [trove][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Trove team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help guide

[openstack-dev] [horizon][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Horizon team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

[openstack-dev] [magnum][tc] Seeking feedback on the OpenStack cloud vision

Greetings, Magnum team! As you may be aware, I've been working with other folks in the community on documenting a vision for OpenStack clouds (formerly known as the 'Technical Vision') - essentially to interpret the mission statement in long-form, in a way that we can use to actually help

Re: [openstack-dev] Proposal for a process to keep up with Python releases

On 22/10/18 10:33 AM, Thomas Goirand wrote: On 10/19/18 5:17 PM, Zane Bitter wrote: We have traditionally held to the principle that we want each release to support the latest release of CentOS and the latest LTS release of Ubuntu, as they existed at the beginning of the release cycle.[2

Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

On 22/10/18 10:38 AM, Thomas Goirand wrote: On 10/22/18 12:55 PM, Chris Dent wrote: My assumption is that it's "something we plan to minimally maintain because we depend on it". in which case all options would work: the exact choice depends on whether there is anybody interested in helping

Re: [openstack-dev] Proposal for a process to keep up with Python releases

On 19/10/18 11:17 AM, Zane Bitter wrote: I'd like to propose that we handle this by setting up a unit test template in openstack-zuul-jobs for each release. So for Stein we'd have openstack-python3-stein-jobs. This template would contain: * A voting gate job for the highest minor version

Re: [openstack-dev] Proposal for a process to keep up with Python releases

On 19/10/18 12:30 PM, Clark Boylan wrote: On Fri, Oct 19, 2018, at 8:17 AM, Zane Bitter wrote: Unit Tests -- For unit tests, the most important thing is to test on the versions of Python we target. It's less important to be using the exact distro that we want to target, because unit

[openstack-dev] Proposal for a process to keep up with Python releases

There hasn't been a Python 2 release in 8 years, and during that time we've gotten used to the idea that that's the way things go. However, with the switch to Python 3 looming (we will drop support for Python 2 in the U release[1]), history is no longer a good guide: Python 3 releases drop as

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 15/10/18 8:00 PM, Monty Taylor wrote: On 10/15/2018 06:39 PM, Zane Bitter wrote: In fact, as far as we know the version we have to support in CentOS may actually be 3.5, which seems like a good reason to keep it working for long enough that we can find out for sure one way or the other

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 15/10/18 4:10 PM, Jeremy Stanley wrote: On 2018-10-15 15:00:07 -0400 (-0400), Zane Bitter wrote: [...] That said, I don't think we should be dropping support/testing for 3.5. According to: https://governance.openstack.org/tc/reference/pti/python.html 3.5 is the only Python3 version

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 12/10/18 8:59 AM, Corey Bryant wrote: On Thu, Oct 11, 2018 at 10:19 AM Andreas Jaeger > wrote: On 10/10/2018 23.10, Jeremy Stanley wrote: > I might have only pointed this out on IRC so far, but the > expectation is that testing 3.5 and 3.6 at the same

Re: [openstack-dev] [kolla][tc] add service discovery, proxysql, vault, fabio and FQDN endpoints

On 10/10/18 1:35 PM, Jay Pipes wrote: +tc topic On 10/10/2018 11:49 AM, Fox, Kevin M wrote: Sorry. Couldn't quite think of the name. I was meaning, openstack project tags. I think having a tag that indicates the project is no longer using SELECT FOR UPDATE (and thus is safe to use

Re: [openstack-dev] [tc] bringing back formal TC meetings

On 4/10/18 1:47 PM, Jeremy Stanley wrote: On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote: [...] TC members, please reply to this thread and indicate if you would find meeting at 1300 UTC on the first Thursday of every month acceptable, and of course include any other comments you

Re: [openstack-dev] [goals][python3][heat][stable] how should we proceed with ocata branch

On 3/10/18 9:42 AM, Matt Riedemann wrote: On 10/3/2018 7:58 AM, Doug Hellmann wrote: There is one more patch to import the zuul configuration for the heat-agents repository's stable/ocata branch. That branch is apparently broken, and Zane suggested on the review [1] that we abandon the patch

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 28/09/18 1:19 PM, Chris Dent wrote: They aren't arbitrary. They are there for a reason: a trait is a boolean capability. It describes something that either a provider is capable of supporting or it isn't. This is somewhat (maybe even only slightly) different from what I think the

Re: [openstack-dev] [placement] The "intended purpose" of traits

On 28/09/18 9:25 AM, Eric Fried wrote: It's time somebody said this. Every time we turn a corner or look under a rug, we find another use case for provider traits in placement. But every time we have to have the argument about whether that use case satisfies the original "intended purpose" of

Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

On 27/09/18 7:00 PM, Duc Truong wrote: On Thu, Sep 27, 2018 at 11:14 AM Zane Bitter wrote: and we will gradually fade out the existing 'AutoScalingGroup' and related resource types in Heat. That's almost impossible to do without breaking existing users. One approach would be to switch

Re: [openstack-dev] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

On 26/09/18 10:27 PM, Qiming Teng wrote: Hi, Due to many reasons, I cannot join you on this event, but I do like to leave some comments here for references. On Tue, Sep 18, 2018 at 11:27:29AM +0800, Rico Lin wrote: *TL;DR* *How about a forum in Berlin for discussing autoscaling integration

Re: [openstack-dev] [Heat] Bug in documentation?

On 26/09/18 12:02 PM, Postlbauer, Juan wrote: Hi everyone: I see that heat doc https://docs.openstack.org/heat/rocky/template_guide/openstack.html#OS::Nova::Flavor states that *ram¶ * Memory in

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists!

On 20/09/18 5:46 PM, Doug Hellmann wrote: Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +: tl;dr: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org

Re: [openstack-dev] [Openstack-sigs] [tc]Global Reachout Proposal

On 18/09/18 9:10 PM, Jaesuk Ahn wrote: On Wed, Sep 19, 2018 at 5:30 AM Zane Bitter <mailto:zbit...@redhat.com>> wrote: Resotring the whole quote here because I accidentally sent the original to the -sigs list only and not the -dev list. As others have mentioned, I think this

Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee

On 17/09/18 5:07 PM, Jay Pipes wrote: Also, for the record, I actually wasn't referring to Adjutant specifically when I referred in my original post to "only tangentially related to cloud computing". I was referring to my recollection of fairly recent history. I remember the seemingly endless

Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee

On 17/09/18 3:06 PM, Jay Pipes wrote: On 09/17/2018 01:31 PM, Doug Hellmann wrote: New Project Application Process === We wrapped up Sunday with a discussion of of our process for reviewing new project applications. Zane and Chris in particular felt the process for

Re: [openstack-dev] [goals][upgrade-checkers] Week R-31 update

On 4/09/18 5:39 PM, Ben Nemec wrote: Would it be helpful to factor some of the common code out into an Oslo library so projects basically just have to subclass, implement check functions, and add them to the _upgrade_checks dict? It's not a huge amount of code, but a bunch of it seems like it

Re: [openstack-dev] [OpenStack-Infra] [StoryBoard] Project Update/Some New Things

On 10/09/18 10:34 AM, Jeremy Stanley wrote: On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote: [...] # Linking to projects by name Keen observers might've noticed that StoryBoard recently grew the ability to link to projects by name, rather than by ID number. All the links to projects

Re: [openstack-dev] [goal][python3] week 3 update

On 27/08/18 15:37, Doug Hellmann wrote: == Next Steps == If your team is ready to have your zuul settings migrated, please let us know by following up to this email. We will start with the volunteers, and then work our way through the other teams. Heat is ready. I already did master (and by

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 18/08/18 18:22, Eric Fried wrote: A year ago we might have developed a feature where one patch would straddle placement and nova. Six months ago we were developing features where those patches were separate but in the same series. Today that's becoming less and less the case: nrp, sharing

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 20/08/18 14:02, Chris Friesen wrote: In order to address the "velocity of change in placement" issues, how about making the main placement folks members of nova-core with the understanding that those powers would only be used in the new placement repo? That kind of 'understanding' is only

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 17/08/18 11:51, Chris Dent wrote: One of the questions that has come up on the etherpad is about how placement should be positioned, as a project, after the extraction. The options are: * A repo within the compute project * Its own project, either:   * working towards being official and

[openstack-dev] [all][tc] Technical Vision statement: feedback sought

The TC has undertaken to attempt to write a technical vision statement for OpenStack that documents the community's consensus on what we're trying to build. To date the only thing we've had to guide us is the mission statement[1], which is exactly one sentence long and uses undefined terms

Re: [openstack-dev] [oslo] Proposing Zane Bitter as oslo.service core

On 15/08/18 16:34, Ben Nemec wrote: Since there were no objections, I've added Zane to the oslo.service core team.  Thanks and welcome, Zane! Thanks team! I'll try not to mess it up :) On 08/03/2018 11:58 AM, Ben Nemec wrote: Hi, Zane has been doing some good work in oslo.service recently

Re: [openstack-dev] [oslo][mox][python3][goal] need help with mox3 and python 3.6

On 14/08/18 15:45, Doug Hellmann wrote: The python 3.6 unit test job has exposed an issue with mox3. It looks like it might just be in the test suite, but I can't tell. I'm looking for one of the folks who suggested we should just keep maintaining mox3 to help fix it. Please go ahead and take

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

Top posting to avoid getting into the weeds. * OpenStack is indeed lagging behind * The road to 3.7 (and eventually 3.8) runs through 3.6 * As part of the project-wide python3-first goal we aim to have everything working on 3.6 for Stein, so we are making some progress at least * As of now we

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

On 06/08/18 13:11, Thomas Goirand wrote: On 08/02/2018 10:43 AM, Andrey Kurilin wrote: There's also some "raise StopIteration" issues in: - ceilometer - cinder - designate - glance - glare - heat - karbor - manila - murano - networking-ovn

Re: [openstack-dev] [OpenStack-dev][heat][keystone][security sig][all] SSL option for keystone session

On 06/08/18 00:46, Rico Lin wrote: Hi all I would like to trigger a discussion on providing directly SSL content for KeyStone session. Since all team using SSL, I believe this maybe concerns to other projects as well. As we consider to implement customize SSL option for Heat remote stack

Re: [openstack-dev] [tc] [all] TC Report 18-26

On 17/07/18 10:44, Thierry Carrez wrote: Finally found the time to properly read this... For anybody else who found the wall of text challenging, I distilled the longest part into a blog post: https://www.zerobanana.com/archive/2018/07/17#openstack-layer-model-limitations Zane Bitter

Re: [openstack-dev] [python3][tc][infra][docs] changing the documentation build PTI to use tox

On 05/07/18 16:46, Doug Hellmann wrote: I have a governance patch up [1] to change the project-testing-interface (PTI) for building documentation to restore the use of tox. We originally changed away from tox because we wanted to have a single standard command that anyone could use to build the

Re: [openstack-dev] [tc] [all] TC Report 18-26

I'm not Kevin but I think I can clarify some of these. On 03/07/18 16:04, Jay Pipes wrote: On 07/03/2018 02:37 PM, Fox, Kevin M wrote: So these days containers are out clouding vms at this use case. So, does Nova continue to be cloudy vm or does it go for the more production vm use case like

Re: [openstack-dev] [tc] [all] TC Report 18-26

On 02/07/18 19:13, Jay Pipes wrote: Also note that when I've said that *OpenStack* should have a smaller mission and scope, that doesn't mean that higher-level services aren't necessary or wanted. Thank you for saying this, and could I please ask you to repeat this disclaimer whenever you

Re: [openstack-dev] [tc] [all] TC Report 18-26

think it would make for a much healthier OpenStack. Thanks, Kevin ________ From: Zane Bitter [zbit...@redhat.com] Sent: Wednesday, June 27, 2018 4:23 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26 On 27/06/18 07:55, Jay P

Re: [openstack-dev] [all][sdk] Integrating OpenStack and k8s with a service broker

Now that the project is set up, let's tag future messages on this topic with [service-broker]. Here's one to start with that will help you find everything: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131923.html cheers, Zane. On 05/06/18 12:19, Zane Bitter wrote: I've been

[openstack-dev] [service-broker] openstack-service-broker project update

(This follows on from http://lists.openstack.org/pipermail/openstack-dev/2018-June/131183.html in case you are confused) Hi folks, Now that the project creation process is largely complete, here are some housekeeping updates: * Let's use the [service-broker] tag in emails to openstack-dev

Re: [openstack-dev] [barbican][heat] Identifying secrets in Barbican

On 28/06/18 15:00, Douglas Mendizabal wrote: Replying inline. [snip] IIRC, using URIs instead of UUIDs was a federation pre-optimization done many years ago when Barbican was brand new and we knew we wanted federation but had no idea how it would work. The rationale was that the URI would

Re: [openstack-dev] [tc] [all] TC Report 18-26

On 27/06/18 07:55, Jay Pipes wrote: WARNING: Danger, Will Robinson! Strong opinions ahead! I'd have been disappointed with anything less :) On 06/26/2018 10:00 PM, Zane Bitter wrote: On 26/06/18 09:12, Jay Pipes wrote: Is (one of) the problem(s) with our community that we have too small

[openstack-dev] [barbican][heat] Identifying secrets in Barbican

We're looking at using Barbican to implement a feature in Heat[1] and ran into some questions about how secrets are identified in the client. With most openstack clients, resources are identified by a UUID. You pass the UUID on the command line (or via the Python API or whatever) and the

Re: [openstack-dev] [tc] [all] TC Report 18-26

On 26/06/18 09:12, Jay Pipes wrote: Is (one of) the problem(s) with our community that we have too small of a scope/footprint? No. Not in the slightest. Incidentally, this is an interesting/amusing example of what we talked about this morning on IRC[1]: you say your concern is that the scope

Re: [openstack-dev] [tc] [all] TC Report 18-26

On 26/06/18 09:12, Jay Pipes wrote: On 06/26/2018 08:41 AM, Chris Dent wrote: Meanwhile, to continue [last week's theme](/tc-report-18-25.html), the TC's role as listener, mediator, and influencer lacks definition. Zane wrote up a blog post explaining the various ways in which the OpenStack

Re: [openstack-dev] [heat][heat-translator][tacker] Need new release of heat-translator library

On 21/06/18 16:37, Sean McGinnis wrote: Apparently heat-translator has a healthy ecosystem of contributors and users, but not of maintainers, and it remaining a deliverable of the Heat project is doing nothing to alleviate the latter problem. I'd like to find it a home that _would_ help. I'd

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

On 20/06/18 17:59, Adam Harwell wrote: Looks like I missed this so I'm late to the party, but: Ade is technically correct, Octavia doesn't explicitly depend on Barbican, as we do support castellan generically. *HOWEVER*: we don't just store and retrieve our own secrets -- we rely on loading

Re: [openstack-dev] [heat][heat-translator][tacker] Need new release of heat-translator library

On 20/06/18 18:59, Doug Hellmann wrote: According to https://governance.openstack.org/tc/reference/projects/heat.html the Heat PTL*is* the PTL for heat-translators. Any internal team structure that implies otherwise is just that, an internal team structure. Yes, correct. I'm really unclear

Re: [openstack-dev] [heat][heat-templates] Creating a role with no domain

On 21/06/18 07:39, Rabi Mishra wrote: Looks like that's a bug where we create a domain specific role for 'default' domain[1], when domain is not specified. [1] https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/keystone/role.py#L54 You can _probably_ pass

Re: [openstack-dev] [heat][tacker][heat-translator] deliverables of heat-translator library

On 20/06/18 12:38, HADDLETON, Robert W (Bob) wrote: The Tacker team is dependent on tosca-parser and heat-translator but they are not the only consumers. I agree the structure is odd, and Sahdev has more of the history than I do. History lesson: At the time (2014) OpenStack was organised

Re: [openstack-dev] [heat] Need new release of heat-translator library

On 20/06/18 11:40, Rico Lin wrote: I send a release patch now https://review.openstack.org/#/c/576895/ Also, add Bob Haddleton to this ML who is considering as PTL for heat-translator team Is it time to consider moving the heat-translator and tosca-parser repos from being deliverables of

[openstack-dev] [all] Non-OpenStack projects under the Foundation umbrella

You may or may not be aware that the Foundation is in the process of expanding its mission to support projects other than OpenStack. It's a confusing topic and it's hard to find information about it all in one place, so I collected everything I was able to piece together during the Summit into

Re: [openstack-dev] [Openstack-operators] [openstack-operators][heat][oslo.db] Configure maximum number of db connections

On 18/06/18 13:39, Jay Pipes wrote: +openstack-dev since I believe this is an issue with the Heat source code. On 06/18/2018 11:19 AM, Spyros Trigazis wrote: Hello list, I'm hitting quite easily this [1] exception with heat. The db server is configured to have 1000 max_connnections and 1000

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

Replying to myself one more time... On 12/06/18 17:35, Zane Bitter wrote: On 11/06/18 18:49, Zane Bitter wrote: It's had a week to percolate (and I've seen quite a few people viewing the etherpad), so here is the review: https://review.openstack.org/574479 In response to comments, I moved

Re: [openstack-dev] [all] [release] How to handle "stable" deliverables releases

On 12/06/18 11:41, Michael Johnson wrote: I think we should continue with option 1. It is an indicator that a project is active in OpenStack and is explicit about which code should be used together. Both of those statements hold no technical water, but address the "human" factor of "What is

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

On 11/06/18 18:49, Zane Bitter wrote: It's had a week to percolate (and I've seen quite a few people viewing the etherpad), so here is the review: https://review.openstack.org/574479 In response to comments, I moved the change to the Project Team Guide instead of the Contributor Guide (since

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

On 04/06/18 10:13, Zane Bitter wrote: On 31/05/18 14:35, Julia Kreger wrote: Back to the topic of nitpicking! I virtually sat down with Doug today and we hammered out the positive aspects that we feel like are the things that we as a community want to see as part of reviews coming out

Re: [openstack-dev] [all][sdk][heat] Integrating OpenStack and k8s with a service broker

On 08/06/18 22:28, Rico Lin wrote: Zane Bitter mailto:zbit...@redhat.com>> 於 2018年6 月9日 週六 上午9:20寫道： > > IIUC you're talking about a Heat resource that calls out to a service > broker using the Open Service Broker API? (Basically acting like the > Kubernetes Service Ca

Re: [openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

On 11/06/18 10:23, Doug Hellmann wrote: Excerpts from Dmitry Tantsur's message of 2018-06-11 16:00:41 +0200: Hi, On 06/11/2018 03:53 PM, Ruby Loo wrote: Hi, I don't want to hijack the initial thread, but am now feeling somewhat guilty about not being vocal wrt Storyboard. Yes, ironic

Re: [openstack-dev] [all][sdk][heat] Integrating OpenStack and k8s with a service broker

On 08/06/18 02:40, Rico Lin wrote: Thanks, Zane for putting this up. It's a great service to expose infrastructure to application, and a potential cross-community works as well. > > Would you be interested in working on a new project to implement this > integration? Reply to this thread and

Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects

On 29/05/18 13:37, Jeremy Stanley wrote: On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: We allow various open source projects that are not an official part of OpenStack or necessarily used by OpenStack to be hosted on OpenStack infrastructure - previously under the 'StackForge

Re: [openstack-dev] [all][sdk] Integrating OpenStack and k8s with a service broker

On 06/06/18 11:18, Chris Hoge wrote: Hi Zane, Do you think this effort would make sense as a subproject within the Cloud Provider OpenStack repository hosted within the Kubernetes org? We have a solid group of people working on the cloud provider, and while it’s not the same code, it’s a

Re: [openstack-dev] [all][python3][tc][infra] Python 3.6

On 05/06/18 16:38, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-05 15:55:49 -0400: We've talked a bit about migrating to Python 3, but (unless I missed it) not a lot about which version of Python 3. Currently all projects that support Python 3 are gating against 3.5.

[openstack-dev] [all][python3][tc][infra] Python 3.6

We've talked a bit about migrating to Python 3, but (unless I missed it) not a lot about which version of Python 3. Currently all projects that support Python 3 are gating against 3.5. However, Ubuntu Artful and Fedora 26 already ship Python 3.6 by default. (And Bionic and F28 have been

[openstack-dev] [all][sdk] Integrating OpenStack and k8s with a service broker

I've been doing some investigation into the Service Catalog in Kubernetes and how we can get OpenStack resources to show up in the catalog for use by applications running in Kubernetes. (The Big 3 public clouds already support this.) The short answer is via an implementation of something

Re: [openstack-dev] [tc] Organizational diversity tag

On 04/06/18 17:52, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400: On 02/06/18 13:23, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: On 01/06/18 12:18, Doug Hellmann wrote: [snip] Is that rule a sign of a

Re: [openstack-dev] [tc] Organizational diversity tag

On 02/06/18 13:23, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: On 01/06/18 12:18, Doug Hellmann wrote: [snip] Is that rule a sign of a healthy team dynamic, that we would want to spread to the whole community? Yeah, this part I am pretty unsure

  1   2   3   4   5   6   7   8   >