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

On 04/06/18 10:19, Amy Marrich wrote: Zane, I'll read in more detail, but do we want to add rollcall-vote? Is it used anywhere other than in the governance repo? We certainly could add it, but it didn't seem like a top priority. - ZB Amy (spotz) On Mon, Jun 4, 2018 at 7:13 AM, Zane

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

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 of this effort. The principles change[1] in

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

On 01/06/18 12:18, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-01 10:10:31 -0400: Crazy idea: what if we dropped the idea of measuring the diversity and allowed teams to decide when they applied the tag to themselves like we do for other tags. (No wait! Come back!) Some

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

On 26/05/18 17:46, Mohammed Naser wrote: Hi everyone! During the TC retrospective at the OpenStack summit last week, the topic of the organizational diversity tag is becoming irrelevant was brought up by Thierry (ttx)[1]. It seems that for projects that are not very active, they can easily

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

On 30/05/18 00:52, Cédric Jeanneret wrote: Another issue is that if the original author needs to rev the patch again for any reason, they then need to figure out how to check out the modified patch. This requires a fairly sophisticated knowledge of both git and gerrit, which isn't a problem for

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

On 29/05/18 16:49, Slawomir Kaplonski wrote: Hi, Wiadomość napisana przez Jay S Bryant w dniu 29.05.2018, o godz. 22:25: Maybe it would be different now that I am a Core/PTL but in the past I had been warned to be careful as it could be misinterpreted if I was changing other people's

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

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' branding, but now without separate branding. Do we document anywhere the terms of service under which

Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

On 23/05/18 11:25, Dean Troyer wrote: On Wed, May 23, 2018 at 12:58 PM, Julia Kreger wrote: There is definitely value to be gained for both projects in terms of a different point of view that might not have been able to play out in Ironic is a bit different in

Re: [openstack-dev] [docs] Automating documentation the tripleo way?

On 16/05/18 13:11, Ben Nemec wrote: On 05/16/2018 10:39 AM, Petr Kovar wrote: Hi all, In the past few years, we've seen several efforts aimed at automating procedural documentation, mostly centered around the OpenStack installation guide. This idea to automatically produce and verify

Re: [openstack-dev] [requirements][barbican][daisycloud][freezer][fuel][heat][pyghmi][rpm-packaging][solum][tatu][trove] pycrypto is dead and insecure, you should migrate

On 13/05/18 13:22, Matthew Thode wrote: This is a reminder to the projects called out that they are using old, unmaintained and probably insecure libraries (it's been dead since 2014). Please migrate off to use the cryptography library. We'd like to drop pycrypto from requirements for rocky.

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

On 11/05/18 11:46, Jay Pipes wrote: On 05/10/2018 08:12 PM, Zane Bitter wrote: On 10/05/18 16:45, Matt Riedemann wrote: On 5/10/2018 3:38 PM, Zane Bitter wrote: How can we avoid (or get out of) the local maximum trap and ensure that OpenStack will meet the needs of all the users we want

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

On 24/04/18 08:35, Chris Dent wrote: The main TC-related activity over the past week has been the [elections](https://governance.openstack.org/election/) currently in progress. A quiet campaigning period burst into late activity with a series of four questions posted in email by Doug Hellman:

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

On 10/05/18 16:52, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-05-10 16:38:37 -0400: On 17/04/18 05:24, Thierry Carrez wrote: Hi everyone, As you know the Technical Committee (the governance body representing contributors producing OpenStack software) meets with other

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

On 10/05/18 16:45, Matt Riedemann wrote: On 5/10/2018 3:38 PM, Zane Bitter wrote: How can we avoid (or get out of) the local maximum trap and ensure that OpenStack will meet the needs of all the users we want to serve, not just those whose needs are similar to those of the users we already

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

On 17/04/18 05:24, Thierry Carrez wrote: Hi everyone, As you know the Technical Committee (the governance body representing contributors producing OpenStack software) meets with other OpenStack governance bodies (Board of Directors and User Committee) on the Sunday before every Summit, and

Re: [openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

On 03/05/18 15:49, Eric K wrote: Question to the projects which send or consume webhook notifications (telemetry, monasca, senlin, vitrage, etc.), what are your supported/preferred authentication mechanisms? Bearer token (e.g. Keystone)? Signing? Signed URLs and regular Keystone auth are both

Re: [openstack-dev] [all][tc][ptls][glance] final stages of python 3 transition

On 08/05/18 15:16, Matthew Treinish wrote: Although, I don't think glance uses oslo.service even in the case where it's using the standalone eventlet server. It looks like it launches eventlet.wsgi directly: https://github.com/openstack/glance/blob/master/glance/common/wsgi.py and I don't see

Re: [openstack-dev] [all][tc][ptls] final stages of python 3 transition

On 30/04/18 17:16, Ben Nemec wrote: Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400: 1. Fix oslo.service functional tests -- the Oslo team needs help     maintaining this library. Alternatively, we could move all     services to use cotyledon

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

On 01/05/18 16:21, Doug Hellmann wrote: Excerpts from Andreas Jaeger's message of 2018-05-01 21:51:19 +0200: On 05/01/2018 04:08 PM, Doug Hellmann wrote: The TC has had an item on our backlog for a while (a year?) to document "constellations" of OpenStack components to make it easier for

Re: [openstack-dev] Following the new PTI for document build, broken local builds

On 25/04/18 11:41, Doug Hellmann wrote: Excerpts from Sean McGinnis's message of 2018-04-25 09:59:13 -0500: I'd be more in favour of changing the zuul job to build with the '-W' flag. To be honest, there is no good reason to not have this flag enabled. I'm not sure that will be a popular

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

On 24/04/18 12:04, Fox, Kevin M wrote: Yeah, I agree k8s seems to have hit on a good model where interests are separately grouped from the code bases. This has allowed architecture to not to be too heavily influenced by the logical groups interest. I'll go ahead and propose it again since its

Re: [openstack-dev] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

On 19/04/18 08:59, Harald Jensås wrote: The problem is getting there using heat ... The real answer is to make everything explicit - create a Subnet resource and a Port resource and don't allow Neutron/Nova to make any decisions for you that would have the effect of hiding data that you

Re: [openstack-dev] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

On 23/04/18 14:09, Dan Sneddon wrote: Yes, the port is currently created as part of the Ironic server resource. We would have more flexibility if this were a separate Neutron port, but we need to be able to support upgrades. This would require the ability in Heat to detach the implicit port

Re: [openstack-dev] [tc] campaign question related to new projects

On 24/04/18 05:55, Thierry Carrez wrote: Zane Bitter wrote: [...] I would love to see us have a conversation as a community to figure out what we all, collectively, think that list should look like and document it. Ideally new projects shouldn't have to wait until they've applied to join

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

On 23/04/18 10:06, Doug Hellmann wrote: [This is meant to be one of (I hope) several conversation-provoking questions directed at prospective TC members to help the community understand their positions before considering how to vote in the ongoing election.] Over the last year we have seen some

Re: [openstack-dev] [tc] campaign question: How "active" should the TC be?

On 23/04/18 09:27, Doug Hellmann wrote: [This is meant to be one of (I hope) several conversation-provoking questions directed at prospective TC members to help the community understand their positions before considering how to vote in the ongoing election.] We frequently have discussions about

Re: [openstack-dev] [tc] campaign question: How should we handle projects with overlapping feature sets?

On 23/04/18 09:50, Doug Hellmann wrote: [This is meant to be one of (I hope) several conversation-provoking questions directed at prospective TC members to help the community understand their positions before considering how to vote in the ongoing election.] In the course of evaluating new

Re: [openstack-dev] [tc] campaign question related to new projects

On 20/04/18 17:26, Doug Hellmann wrote: [This is meant to be one of (I hope) several conversation-provoking questions directed at prospective TC members to help the community understand their positions before considering how to vote in the ongoing election.] Thanks Doug, I think this is a

[openstack-dev] [TC][election] TC Candidacy

Hello friends, I've been working full-time on OpenStack for 6 years now, since the very early days of the Heat project back in 2012. Along the way I have served as PTL of Heat, where I am still a member of the core team, and colloborated with developers from many other projects, such as

Re: [openstack-dev] Following the new PTI for document build, broken local builds

On 21/03/18 06:49, Stephen Finucane wrote: As noted by Monty in a prior openstack-dev post [2], some projects rely on a pbr extension to the 'build_sphinx' setuptools command which can automatically run the 'sphinx-apidoc' tool before building docs. This is enabled by configuring some settings

Re: [openstack-dev] Asking for ask.openstack.org

On 05/04/18 00:12, Ian Wienand wrote: On 04/05/2018 10:23 AM, Zane Bitter wrote: On 04/04/18 17:26, Jimmy McArthur wrote: Here's the thing: email alerts. They're broken. This is the type of thing we can fix if we know about it ... I will contact you off-list because the last email to what I

Re: [openstack-dev] Asking for ask.openstack.org

On 04/04/18 17:26, Jimmy McArthur wrote: Hi everyone! We have a very robust and vibrant community at ask.openstack.org .  There are literally dozens of posts a day. However, many of them don't receive knowledgeable answers.  I'm really worried about this becoming

Re: [openstack-dev] Replacing pbr's autodoc feature with sphinxcontrib-apidoc

On 03/04/18 06:28, Stephen Finucane wrote: On Mon, 2018-04-02 at 19:41 -0400, Zane Bitter wrote: On 28/03/18 10:31, Stephen Finucane wrote: As noted last week [1], we're trying to move away from pbr's autodoc feature as part of the new docs PTI. To that end, I've created sphinxcontrib-apidoc

Re: [openstack-dev] Replacing pbr's autodoc feature with sphinxcontrib-apidoc

On 28/03/18 10:31, Stephen Finucane wrote: As noted last week [1], we're trying to move away from pbr's autodoc feature as part of the new docs PTI. To that end, I've created sphinxcontrib-apidoc, which should do what pbr was previously doing for us by via a Sphinx extension.

Re: [openstack-dev] [openstack-ops][heat][PTG] Heat PTG Summary

On 15/03/18 04:01, Rico Lin wrote: Hi Heat devs and ops It's a great PTG plus SnowpenStack experience. Now Rocky started. We really need all kind of input and effort to make sure we're heading toward the right way. Here is what we been discussed during PTG: * Future strategy for

Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

On 08/03/18 19:31, Doug Hellmann wrote: If these new plugins might contain "candidate" tests and all tests are potentially candidates, how are these new repos different from the existing repos that already contain all of the tests? We have to allow candidate tests because otherwise there's a

Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

On 08/03/18 12:57, Doug Hellmann wrote: Why would the repos be owned by anyone other than the original project team? A few reasons I think it makes sense in this instance: * Not every set of trademark tests will necessarily belong to a single project. Tempest itself is an example of this -

Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

On 07/03/18 08:44, Ghanshyam Mann wrote: I mean i am all ok with separate plugin which is more easy for QA team but ownership to QA is kind of going to same direction(QA team maintaining interop ads-on tests) in more difficult way. After reading this and the logs from the QA meeting,[1] I

[openstack-dev] [heat] tracking the mox removal work

I know how eager you all are to start replacing mox with mock, so I created a spreadsheet to help us avoid tripping over each other in our enthusiasm to get it done: https://ethercalc.openstack.org/heat-mox-removal Please add links to your patches in there as you create them. This will help

Re: [openstack-dev] [yaql] [tripleo] Backward incompatible change in YAQL minor version

On 17/02/18 16:40, Dan Prince wrote: Thanks for the update Emilien. A couple of things to add: 1) This was really difficult to pin-point via the Heat stack error message ('list index out of range'). I actually had to go and add LOG.debug statements to Heat to get to the bottom of it. I aim to

Re: [openstack-dev] [all][Kingbird][Heat][Glance]Multi-Region Orchestrator

On 07/02/18 12:24, Goutham Pratapa wrote: >Yes as you said it can be interpreted as a tool that can orchestrate multiple-regions. Actually from your additional information I'm now getting the impression that you are, in fact, positioning this as a partial competitor to Heat.

Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator

On 07/02/18 11:20, Chris Friesen wrote: One use-case I've seen for this sort of thing is someone that has multiple geographically-separate clouds, and maybe they want to run the same heat stack in all of them. Something like "create a keypair in each of the clouds with the same public key

Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator

On 31/01/18 01:49, Goutham Pratapa wrote: *Kingbird (The Multi Region orchestrator):* We are proud to announce kingbird is not only a centralized quota and resource-manager but also a  Multi-region Orchestrator. I'd invite you to consider coming up with a different short description for the

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On 30/01/18 10:33, Colleen Murphy wrote: At the last PTG we had some time on Monday and Tuesday for cross-project discussions related to baremetal and VM management. We don't currently have that on the schedule for this PTG. There is still some free time available that we can ask for[1]. Should

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

On 25/01/18 19:08, James E. Blair wrote: Mathieu Gagné writes: On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec wrote: I'm curious what this means as far as best practices for inter-patch references. In the past my understanding was the the change id

Re: [openstack-dev] [all] Switching to longer development cycles

On 19/12/17 22:15, Fei Long Wang wrote: On 20/12/17 09:29, Joshua Harlow wrote: Zane Bitter wrote: Getting off-topic, but since you walked in to this one ;) On 14/12/17 21:43, Matt Riedemann wrote: What are the real problems that the Nova team is not working on and apparently is a priority

Re: [openstack-dev] [all] Switching to longer development cycles

Getting off-topic, but since you walked in to this one ;) On 14/12/17 21:43, Matt Riedemann wrote: What are the real problems that the Nova team is not working on and apparently is a priority to everyone else in the OpenStack ecosystem but we are somehow oblivious? * Providing a secure

Re: [openstack-dev] [all] Switching to longer development cycles

On 13/12/17 11:17, Thierry Carrez wrote: So... What do you think ? Some points against that I haven't seen mentioned much yet: * Following our standard deprecation policy, it would take up to 3 years to remove anything. For perspective, 3 years ago we had just shipped Juno. (I feel old

Re: [openstack-dev] [all] cyclomatic complexity check in flake8 & Python 3

On 12/12/17 08:40, Sean Dague wrote: On 12/12/2017 08:08 AM, Thierry Carrez wrote: Zane Bitter wrote: Here's how the allegedly most complex function in Heat[5] shakes out, for example:   mccabe  py27  py36   0.2.1    14 6   0.3.1    23    23   0.6.1    23    23 I don't have

[openstack-dev] [all] cyclomatic complexity check in flake8 & Python 3

We have around 60 repos using the 'mccabe' package to do cyclomatic complexity checks in flake8 in their gate jobs.[1] Based on advice received at the time[2], the version of mccabe that we use in the gate is effectively pinned to 0.2.1 by hacking (the project, not... never mind).[3] This is

Re: [openstack-dev] [Tripleo] Some historic digging

On 08/12/17 03:51, Cédric Jeanneret wrote: On 12/07/2017 05:23 PM, Steven Hardy wrote: On Thu, Dec 7, 2017 at 7:22 AM, Cédric Jeanneret wrote: After some more digging, it appears the "dot" (".") in YAML is a reserved char for hashes. In the puppet world, we

Re: [openstack-dev] [Release-job-failures][heat] Release of openstack/python-heatclient failed

On 07/12/17 11:13, Doug Hellmann wrote: Excerpts from zuul's message of 2017-12-07 15:00:43 +: Build failed. - release-openstack-python http://logs.openstack.org/7a/7a54c5881cdd26d89775b638628c3f9c909a33a6/release/release-openstack-python/e5594bb/ : SUCCESS in 5m 41s - announce-release

Re: [openstack-dev] [heat][qa] Split tempest plugin from heat

OK, an update on this. The current plan of record after the team meeting today goes something like this: 1) Identify tests that are moving to the new plugin repo, and remove them from the heat repo. 2) Start using the utils (base classes ) from the plugin repo in the remaining heat tests. 3)

Re: [openstack-dev] [heat][qa] Split tempest plugin from heat

On 19/11/17 03:08, Rabi Mishra wrote: Hi All, As part of community goal[1] for Queens, we've completed the repo split and created the new project[2]. The next objective to is to use the new plugin in our jobs. As we've merged some changes after the split, I've synced them and fixed some

Re: [openstack-dev] [heat] Meaning of "updated" in stack update preview / --dry-run?

On 08/11/17 07:19, James Wettenhall wrote: Hi, I have some stacks created by heat which I want to update. I download the current template with "heat template-show". Then before modifying the template, I try running "heat stack-update" with "--dry-run" to see what will be changed (if

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

On 20/10/17 20:20, Tony Breeds wrote: Hi All, With the election behind us it's somewhat traditional to look at some simple stats from the elections: +--+---+---+---+ | Election | Electorate (delta %) | Voted (delta %) |

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

On 17/10/17 14:16, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2017-10-16 18:10:20 -0400: On 14/10/17 11:47, Doug Hellmann wrote: Even the rewritten question can be answered legitimately using several different personas by people with a bit of experience. I have worked at a

Re: [openstack-dev] [oslo][blazar][heat] Remove oslotest.mockpatch

On 16/10/17 09:53, ChangBo Guo wrote: The oslotest.mockpatch has been deprecated in favor of native fixtures in [1] , need remove its usage in python-heatclient, python-blazarclient [2][3], Heat/Blazar team please help review, then we'll merge [4] [1]https://review.openstack.org/#/c/245199/

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

On 14/10/17 11:47, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2017-10-13 15:21:14 -0400: Replying to myself here, to avoid singling anyone in particular out. I want to rephrase the question, because people are overwhelmingly either failing to understand or refusing to answer it

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

*end* user persona for OpenStack that you're familiar enough with to be comfortable advocating for on the TC. So far the answer I'm hearing mostly translates as 'no'. (Props to the folks who did actually answer though!) Does anybody want to try again? cheers, Zane. On 12/10/17 12:51, Zane

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

On 12/10/17 19:43, Fox, Kevin M wrote: I slightly disagree. I think there are 3 sets of users not 2... Operators, Tenant Users, and Tenant Application Developers. Tenant Application Developers develop software that the Tenant Users deploy in their tenant. Most OpenStack developers consider

Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

On 12/10/17 15:07, Mohammed Naser wrote: Hi Zane, Thank you for your question. I think you're raising a critical question which we must all come to (fairly relative) agreement to so that we can all build OpenStack in the same direction. On Thu, Oct 12, 2017 at 12:51 PM, Zane Bitter <z

[openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?

(Reminder: we are in the TC election campaigning period, and we all have the opportunity to question the candidates. The campaigning period ends on Saturday, so make with the questions.) In my head, I have a mental picture of who I'm building OpenStack for. When I'm making design decisions I

Re: [openstack-dev] What logical clock does OpenStack use

On 11/10/17 02:48, Puneet Jain wrote: Hi, I was just curious to know, how the event ordering happens in OpenStack? You might have mistaken OpenStack for a distributed system :) What clock does it use? I mean does it use Lamport Logical Clock? MySQL

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

On 12/09/17 18:58, Colleen Murphy wrote: While it's fresh in our minds, I wanted to write up a short recap of where we landed in the Application Credentials discussion in the BM/VM room today. For convenience the (as of yet unrevised) spec is here: Thanks so much for staying on this Colleen,

Re: [openstack-dev] [policy] AWS IAM session

On 03/10/17 16:08, Lance Bragstad wrote: Hey all, It was mentioned in today's keystone meeting [0] that it would be useful to go through AWS IAM (or even GKE) as a group. With all the recent policy discussions and work, it seems useful to get our eyes on another system. The idea would be to

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

On 19/07/17 23:19, Monty Taylor wrote: Instance users do not solve this. Instance users can be built with this- but instance users are themselves not sufficient. Instance users are only sufficient in single-cloud ecosystems where it is possible to grant permissions on all the resources in

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

On 19/07/17 22:27, Monty Taylor wrote: I propose we set aside time at the PTG to dig in to this. Between Zane and I and the Keystone core team I have confidence we can find a way out. This may be a bad time to mention that regrettably I won't be attending the PTG, due to (happy!) family

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

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 credentials dependent on several cycles of policy

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

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 credentials dependent on several cycles of policy

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

So the application credentials spec has merged - huge thanks to Monty and the Keystone team for getting this done: https://review.openstack.org/#/c/450415/ http://specs.openstack.org/openstack/keystone-specs/specs/keystone/pike/application-credentials.html However, it appears that there was a

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

unlikely to go away ;) cheers, Zane. [1] https://twitter.com/jaypipes/status/885278601821769728 On 14/07/17 05:03, Zane Bitter wrote: On 29/06/17 10:55, Monty Taylor wrote: (Incidentally, I think it's unworkable to have an IaaS without DNS. Other people have told me that having

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

On 29/06/17 10:55, Monty Taylor wrote: (Incidentally, I think it's unworkable to have an IaaS without DNS. Other people have told me that having an IaaS without LBaaS or a message queuing service is unworkable, while I neither need nor want either of those things from my IaaS - they seem like

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

On 29/06/17 10:18, Jeremy Stanley wrote: Gerrit's design assumes project names (including any prefixed namespace) never change. This means project renames in Gerrit are painful and disruptive (service outage for everyone, Git remote changes for anyone working on that repo, risk of breaking

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 23/06/17 05:31, Thierry Carrez wrote: Zane Bitter wrote: But back in the day we had a process (incubation) for adding stuff to OpenStack that it made sense to depend on being there. It was a highly imperfect process. We got rid of that process with the big tent reform, but didn't really

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

(Top posting. Deal with it ;) You're both right! Making OpenStack monolithic is not the answer. In fact, rearranging Git repos has nothing to do with the answer. But back in the day we had a process (incubation) for adding stuff to OpenStack that it made sense to depend on being there. It

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 21/06/17 01:49, Mark Kirkwood wrote: On 21/06/17 02:08, Jay Pipes wrote: On 06/20/2017 09:42 AM, Doug Hellmann wrote: Does "service VM" need to be a first-class thing? Akanda creates them, using a service user. The VMs are tied to a "router" which is the billable resource that the user

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 20/06/17 11:45, Jay Pipes wrote: Good discussion, Zane. Comments inline. ++ On 06/20/2017 11:01 AM, Zane Bitter wrote: On 20/06/17 10:08, Jay Pipes wrote: On 06/20/2017 09:42 AM, Doug Hellmann wrote: Does "service VM" need to be a first-class thing? Akanda creates t

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 20/06/17 10:08, Jay Pipes wrote: On 06/20/2017 09:42 AM, Doug Hellmann wrote: Does "service VM" need to be a first-class thing? Akanda creates them, using a service user. The VMs are tied to a "router" which is the billable resource that the user understands and interacts with through the

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 18/06/17 07:35, Amrith Kumar wrote: Trove has evolved rapidly over the past several years, since integration in IceHouse when it only supported single instances of a few databases. Today it supports a dozen databases including clusters and replication. The user survey [1] indicates that

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 19/06/17 20:56, Curtis wrote: I really think the concept of "service VMs" should be a thing. I'm not sure where the OpenStack community has landed on that, my fault for not paying close attention, but we should be able to create VMs for a tenant that are not managed by the tenant but that

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

On 16/06/17 05:09, Kaz Shinohara wrote: I still takes `deferred _auth_method=password` behalf of trusts because we don't enable trusts in the Keystone side due to some internal reason. Free advice: whatever reason you have for not enabling trusts, storing user passwords in the Heat database

Re: [openstack-dev] [heat][tripleo] Making stack outputs static

On 13/06/17 13:00, Ben Nemec wrote: On 06/12/2017 03:53 PM, Zane Bitter wrote: On 12/06/17 16:21, Steven Hardy wrote: I think we wanted to move to convergence anyway so I don't see a problem with this. I know there was some discussion about starting to test with convergence in tripleo-ci

Re: [openstack-dev] [heat] Making stack outputs static

On 12/06/17 16:21, Steven Hardy wrote: I think we wanted to move to convergence anyway so I don't see a problem with this. I know there was some discussion about starting to test with convergence in tripleo-ci, does anyone know what, if anything, happened with that? There's an experimental job

[openstack-dev] [heat] Making stack outputs static

History lesson: a long, long time ago we made a very big mistake. We treated stack outputs as things that would be resolved dynamically when you requested them, instead of having values fixed at the time the template was created or updated. This makes performance of reading outputs slow,

Re: [openstack-dev] [qa] [tc] [all] more tempest plugins (was Re: [tc] [all] TC Report 22)

On 05/06/17 09:43, Sean Dague wrote: On 06/01/2017 06:09 AM, Chris Dent wrote: It's clear from this thread and other conversations that the management of tempest plugins is creating a multiplicity of issues and confusions: * Some projects are required to use plugins and some are not. This

Re: [openstack-dev] [qa] [tc] [all] more tempest plugins (was Re: [tc] [all] TC Report 22)

On 31/05/17 09:43, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2017-05-31 11:22:50 +0100: On Wed, 31 May 2017, Graham Hayes wrote: On 30/05/17 19:09, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2017-05-30 18:16:25 +0100: Note that this goal only applies to

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

On 25/05/17 18:34, Matt Riedemann wrote: On 5/22/2017 11:01 AM, Zane Bitter wrote: If the user does a stack update that changes the network from 'auto' to 'none', or vice-versa. OK I guess we should make this a side discussion at some point, or hit me up in IRC, but if you're requesting

Re: [openstack-dev] [Heat] revised structure of the heat-templates repository. Suggestions

On 19/05/17 11:00, Lance Haig wrote: Hi, As we know the heat-templates repository has become out of date in some respects and also has been difficult to be maintained from a community perspective. For me the repository is quiet confusing with different styles that are used to show certain

Re: [openstack-dev] [Heat] revised structure of the heat-templates repository. Suggestions

On 22/05/17 12:49, Lance Haig wrote: I also asked the other day if there is a list of heat version matched to Openstack version and I was told that there is not. You mean like https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#ocata ?

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

On 21/05/17 15:38, Monty Taylor wrote: One might argue that HA strategies are an operator concern, but in reality the set of workable HA strategies is tightly constrained by how the application works, and the pairing an application expecting one HA strategy with a deployment implementing a

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

, 2017 at 3:29 PM, Zane Bitter <zbit...@redhat.com <mailto:zbit...@redhat.com>> wrote: On 19/05/17 17:03, Kevin Benton wrote: I split this conversation off of the "Is the pendulum swinging on PaaS layers?" thread [1] to discuss some im

Re: [openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

On 23/05/17 01:23, Rabi Mishra wrote: Hi All, As per the updated community goal[1] for api deployment with wsgi, we've to transition to use uwsgi rather than mod_wsgi at the gate. It also seems mod_wsgi support would be removed from devstack in Queens. I've been working on a patch[2] for the

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

On 22/05/17 22:58, Jay Pipes wrote: On 05/22/2017 12:01 PM, Zane Bitter wrote: On 19/05/17 17:59, Matt Riedemann wrote: I'm not really sure what you're referring to here with 'update' and [1]. Can you expand on that? I know it's a bit of a tangent. If the user does a stack update

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

On 23/05/17 08:35, Alexandra Settle wrote: So, I’ve been a docs core for the OpenStack-Ansible project for some time now and this works really well within our structure. I do not merge anything unless it has a dev +2 before I come along (unless it is a trivial doc-only spelling/grammar

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

On 22/05/17 05:39, Alexandra Settle wrote: 1. We could combine all of the documentation builds, so that each project has a single doc/source directory that includes developer, contributor, and user documentation. This option would reduce the number of build jobs we have to run, and cut down on

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

On 19/05/17 17:59, Matt Riedemann wrote: On 5/19/2017 9:36 AM, Zane Bitter wrote: The problem is that orchestration done inside APIs is very easy to do badly in ways that cause lots of downstream pain for users and external orchestrators. For example, Nova already does some orchestration

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

Cheers, Kevin Benton On Fri, May 19, 2017 at 1:05 PM, Zane Bitter <zbit...@redhat.com <mailto:zbit...@redhat.com>> 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

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

. It's a huge amount of work to research it all though. cheers, Zane. On Fri, May 19, 2017 at 7:36 AM, Zane Bitter <zbit...@redhat.com <mailto:zbit...@redhat.com>> wrote: On 18/05/17 20:19, Matt Riedemann wrote: I just wanted to blurt this out since it hit me a few time

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

On 18/05/17 20:19, Matt Riedemann wrote: I just wanted to blurt this out since it hit me a few times at the summit, and see if I'm misreading the rooms. For the last few years, Nova has pushed back on adding orchestration to the compute API, and even define a policy for it since it comes up so

<    1   2   3   4   5   6   7   8   >