Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [QA] Proposal for a QA SIG
Rochelle Grober wrote: > Thierry Carrez wrote: >> One question I have is whether we'd need to keep the "QA" project team at >> all. Personally I think it would create confusion to keep it around, for no >> gain. >> SIGs code contributors get voting rights for the TC anyway, and SIGs are free >> to ask for space at the PTG... so there is really no reason (imho) to keep a >> "QA" project team in parallel to the SIG ? > > Well, you can get rid of the "QA Project Team" but you would then need to > replace it with something like the Tempest Project, or perhaps the Test > Project. You still need a PTL and cores to write, review and merge tempest > fixes and upgrades, along with some of the tests. The Interop Guideline > tests are part of Tempest because being there provides oversight on the style > and quality of the code of those tests. We still need that. SIGs can totally produce some code (and have review teams), but I agree that in this case this code is basically a part of "the product" (rather than a tool produced by guild of practitioners) and therefore makes sense to be kept in an upstream project team. Let's keep things the way they are, while we work out other changes that may trigger other organizational shuffles (like reusing our project infrastructure beyond just OpenStack). I wonder if we should not call the SIG under a different name to reduce the confusion between QA-the-project-team and QA-the-SIG. Collaborative Testing SIG? -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [Openstack-operators] [QA] Proposal for a QA SIG
Andrea Frittoli wrote: > [...] > during the last summit in Sydney we discussed the possibility of creating an > OpenStack quality assurance special interest group (OpenStack QA SIG). > The proposal was discussed during the QA feedback session [0] and it > received > positive feedback there; I would like to bring now the proposal to a larger > audience via the SIG, dev and operators mailing lists. > [...] I think this goes with the current trends of re-centering upstream "project teams" on the production of software, while using SIGs as communities of practice (beyond the governance boundaries), even if they happen to produce (some) software as the result of their work. One question I have is whether we'd need to keep the "QA" project team at all. Personally I think it would create confusion to keep it around, for no gain. SIGs code contributors get voting rights for the TC anyway, and SIGs are free to ask for space at the PTG... so there is really no reason (imho) to keep a "QA" project team in parallel to the SIG ? In the same vein we are looking into turning the Security project team into a SIG, and could consider turning other non-purely-upstream teams (like I18n) in the future. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, November 17th
Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of all open topics (updated twice a week) at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker If you are working on something (or plan to work on something) that is not on the tracker, feel free to add to it ! == Recently-approved changes == * Add the supports-rolling-upgrade tag to Ironic [1] * Select Thierry Carrez as TC chair [2] * Update house rules to reflect absence of meetings [3] * Split up sahara deliverables [4] [5] * Goal updates: sahara, glance, senlin, designate, zun, zaqar * New repos: os_congress, ansible-role-k8s-(keystone|mariadb|tripleo), tripleo-common-tempest-plugin, cloudkitty-tempest-plugin, cinder-tempest-plugin [1] https://review.openstack.org/#/c/514448/ [2] https://review.openstack.org/#/c/514553/ [3] https://review.openstack.org/#/c/514582/ [4] https://review.openstack.org/#/c/515513/ [5] https://review.openstack.org/#/c/515780/ Low activity over the past 3 weeks as travel to Sydney, Summit week and travel back from Sydney ate most of the TC members time. Most interesting change is the addition of the supports-rolling-upgrade tag to Ironic, to reflect that an Ironic installation can now to upgraded in a rolling fashion. You can find more details about this assertion at: https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html == Voting in progress == The LOCI team (packaging OCI container images for OpenStack deliverables) is being proposed as an official OpenStack project. The addition (and the followup typo fix) seem consensual, but are still missing a couple of votes: https://review.openstack.org/513851 https://review.openstack.org/516005 == Under review == It's time to propose and review community-wide goals for the Rocky cycle. Kendall Nelson posted a proposal around Storyboard Migration. Please review it at: https://review.openstack.org/513875 Matt Treinish proposed an update to the Python PTI for tests to be specific and explicit. Please review at: https://review.openstack.org/519751 As a result of the discussion around stable policy in Sydney, it was proposed to recenter the Stable policy on OpenStack cloud components rather than expect it from all sorts of deliverables. As a result, Emilien proposed the removal of the tag from Kolla[6], while I proposed wording changes to the tag definition[7] [6] https://review.openstack.org/#/c/519685/ [7] https://review.openstack.org/521049 It should not be necessary to wait until we have 5 items in our "help wanted" list, nor require the presence of 5 elements at all times. Please review the list rename at: https://review.openstack.org/520619 The Mogan team application is still up for review. General feedback from the Summit forum session was that the overlap and complementarity between Nova, Ironic and Mogan makes for a complex landscape, and the strategy going forward needs to be clarified before we can approve this application. It is therefore likely that it will be delayed until Rocky, Please comment at: https://review.openstack.org/#/c/508400/ Finally, you might be interested in reviewing the addition of the supports-accessible-upgrade tag to ironic, before it gets approved by lazy consensus: https://review.openstack.org/#/c/516671/ == TC member actions for the coming week(s) == TC members should prepare for Sydney activities (see below). Monty should answer the feedback on the supported database version resolution (https://review.openstack.org/493932) so that we can make progress there -- or abandon it. Doug should update or abandon the "champions and stewards" top help wanted addition (https://review.openstack.org/510656) Thierry should clarify the situation of the Stackube application (https://review.openstack.org/#/c/462460/), in light of the refocus of OpenStack on cloud infrastructure and potential creation in the future of a separate strategic area around container infrastructure. == Office hours == To be more inclusive of all timezones and more mindful of people for which English is not the primary language, the Technical Committee dropped its dependency on weekly meetings. So that you can still get hold of TC members on IRC, we instituted a series of office hours on #openstack-tc: * 09:00 UTC on Tuesdays * 01:00 UTC on Wednesdays * 15:00 UTC on Thursdays For the coming week, I expect the main topic of discussion to be actions coming out of the Forum sessions. Cheers, -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases
John Dickinson wrote: > What I heard from ops in the room is that they want (to start) one > release a year who's branch isn't deleted after a year. What if that's > exactly what we did? I propose that OpenStack only do one release a year > instead of two. We still keep N-2 stable releases around. We still do > backports to all open stable branches. We still do all the things we're > doing now, we just do it once a year instead of twice. I started a thread around this specific suggestion on the -sigs list at: http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000149.html Please continue the discussion there, to avoid the cross-posting. If you haven't already, please subscribe at: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] Upstream LTS Releases
I suggested by Rocky, I moved the discussion to the -sigs list by posting my promised summary of the session at: http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000148.html Please continue the discussion there, to avoid the cross-posting. If you haven't already, please subscribe at: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases
Rochelle Grober wrote: > Folks, > > This discussion and the people interested in it seem like a perfect > application of the SIG process. By turning LTS into a SIG, everyone can > discuss the issues on the SIG mailing list and the discussion shouldn't end > up split. If it turns into a project, great. If a solution is found that > doesn't need a new project, great. Even once there is a decision on how to > move forward, there will still be implementation issues and enhancements, so > the SIG could very well be long-lived. But the important aspect of this is: > keeping the discussion in a place where both devs and ops can follow the > whole thing and act on recommendations. That's an excellent suggestion, Rocky. Moving the discussion to a SIG around LTS / longer-support / post-EOL support would also be a great way to form a team to work on that. Yes, there is a one-time pain involved with subscribing to the -sigs ML, but I'd say that it's a good idea anyway, and this minimal friction might reduce the discussion to people that might actually help with setting something up. So join: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs While I'm not sure that's the best name for it, as suggested by Rocky let's use [lts] as a prefix there. I'll start a couple of threads. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] Upstream LTS Releases
Erik McCormick wrote: > This morning at the Sydney Summit we had a very well attended and very > productive session about how to go about keeping a selection of past > releases available and maintained for a longer period of time (LTS). > > There was agreement in the room that this could be accomplished by > moving the responsibility for those releases from the Stable Branch > team down to those who are already creating and testing patches for > old releases: The distros, deployers, and operators. > > The concept, in general, is to create a new set of cores from these > groups, and use 3rd party CI to validate patches. There are lots of > details to be worked out yet, but our amazing UC (User Committee) will > be begin working out the details. I took the action of summarizing the discussion in more detail, will do as soon as my brain is not as mushy, which might take a couple of weeks :) Note that it's not really about devs vs. ops, with devs abdicating all responsibility on stable branches : it's about allowing collaboration on patches beyond EOL (which is what we are able to support with "live" stable branches on evolving OS/PyPI substrate) and enable whoever steps up to maintain longer-lived branches to come up with a set of tests that actually match their needs (tests that would be less likely to bitrot due to changing OS/PyPI substrate). A number of people from all backgrounds volunteered to flesh out a more detailed proposal. Watch that space! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [security] Security SIG
Luke Hinds wrote: > [...] > Something else which comes to mind; it seems to me we are more of a > 'working group', are working groups no longer a thing in OpenStack? - > SIG seems like a better fit for topics focused mainly on cross project > collaborations efforts (API's being a good example), whereas we have a > lot of group like tasks that we handle in silo? Working groups are still a thing, but they are tied to a specific governance body (TC, UC, Board of Directors). SIGs are cross-community working groups, beyond a single governance body. Project teams are a form of TC-owned working group dedicated to the production of OpenStack software. With security having so much operational ties, it feels like a SIG would be the best match as it prevents artificial governance boundaries from getting in the way of getting people more directly involved. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [forum] Sydney Forum etherpad list
Michael Still wrote: > The privsep session doesn't appear to be in that list. Did it get > dropped or something? It's definitely on the schedule. You have to create and link to the etherpad yourself, though... -- Thierry Carrez (ttx) __ 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
[openstack-dev] [forum] Sydney Forum etherpad list
Hi everyone, Etherpads for the Forum sessions in Sydney can be found here: https://wiki.openstack.org/wiki/Forum/Sydney2017 If you are moderating such a session and the etherpad is missing, please add it ! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc] [all] TC Report 43
Mike Perez wrote: > On 11:17 Oct 25, Flavio Percoco wrote: >> On 24/10/17 19:26 +0100, Chris Dent wrote: >>> It's clear that anyone and everyone _could_ write their own blogs and >>> syndicate to the [OpenStack planet](http://planet.openstack.org/) but >>> this doesn't have the same panache and potential cadence as an >>> official thing _might_. It comes down to people having the time. Eking >>> out the time for this blog, for example, can be challenging. >>> >>> Since this is the second [week in a >>> row](https://anticdent.org/tc-report-42.html) that Josh showed up with >>> an idea, I wonder what next week will bring? >> >> I might not be exactly the same but, I think the superuser's blog could be a >> good place to do some of this writing. There are posts of various kinds in >> that >> blog: technical, community, news, etc. I wonder how many folks from the >> community are aware of it and how many would be willing to contribute to it >> too. >> Contributing to the superuser's blog is quite simple, really. > > Anne used to do TC updates and they were posted to the OpenStack Blog: > > https://www.openstack.org/blog/category/technical-committee-updates/ Those were actually officially published by the Technical Committee (prepared by the "communications" workgroup that Anne was leading), so they were reviewed by TC members and represented the consensual view. There are really only two options: Editorial content to some official publication, where the posts are vetted by a review committee for correctness/consensus: that's what SuperUser is doing, and what the "official blog" was(?) doing. Personal content, where opinionated blogs are automatically aggregated with minimal on-topic checks: that's what the planet is doing. (Sometimes, a personal blog post makes great SuperUser content and is copied over) We could add a specific, technically-focused editorial outlet, or we could set up a specific, technically-focused personal blog aggregator. But I feel like we could also reuse the SuperUser publication and the existing Planet. The main issue seems to be the lack of produced content, rather than lack of discoverability of the existing outlets... -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [security] Security SIG
Luke Hinds wrote: > On Fri, Oct 27, 2017 at 6:08 PM, Jeremy Stanley <mailto:fu...@yuggoth.org>> wrote: > >> On 2017-10-27 15:30:34 +0200 (+0200), Thierry Carrez wrote: >>> [...] >>> I think the Security project team would benefit from becoming a >>> proper SIG. >>> [...] >> I tend to agree, though it's worth also considering what the >> implications are for vulnerability management under the new model. >> The VMT tended to act as an independent task force in the >> beforetime, until the big t^W^Wproject reform of 2014, and then >> allied itself with the newly-formed Security Team while continuing >> operation autonomously under a fairly independent mandate. Does this >> still make sense in a Security SIG context, or should we be >> considering alternative (perhaps more formal?) governance for the >> VMT in that scenario? I don't have especially cogent thoughts around >> this yet, so interested to hear what others in the community think. So the activity of the Security project team can be split into a number of things: - Security advisories for supported projects (ossa by the VMT subteam) - General security notices / information (ossn) - Promotion of secure coding practices (bandit, syntribos) - Promotion of secure operations (security-doc, anchor) - Audit activities (security-analysis) The only thing here that is not performed by an open group is the VMT stuff. It also happens to be the most "upstream" of all the team activity: it's closely related to stable branch maintenance. Personally I think the VMT would be better split off from a Security SIG -- it's suboptimal to have a part of a SIG to be a restricted group. It could be made it's own team, or attached to an existing group (stable branch maintenance) or converted to a TC-owned "workgroup" (a TC delegation of power, like it's always been). > We discussed the SIG proposal on the security meeting and I planned to > invite you in for a session to discuss Thierry (apologies for being late > for getting this together). > > Overall folks thought it an idea worth while enough to explore further. > > My own view is that if its leads to getting more eyes on security, then > its a good thing. With that in mind, I had the idea that we could run a > "Security SIG" in parallel to the security project and see if it gains > traction and security minded people from the wider community do actually > come forward to get involved and merit the change worth while (and it's > not just the Security Project rearranging the furniture). We could then > review how its gone at the end of the Queens cycle and if a success (not > sure how we would define that as yet), then implement the change at the > juncture of a new release. Sure, we can definitely try it out and keep the project team around while we try. The only issue I see with that approach is that it's a bit confusing, and not as strong of a statement compared to saying "all the security activity now happens there". But if you feel more comfortable that way, we can definitely follow that road. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [security] Security SIG
Hi everyone, Once upon a time we only had one governance construct to recognize activity in OpenStack, and that was the upstream project teams. As a result, we created teams for everything. However with the introduction of SIGs, we have a new construct for activities that are not mainly about producing OpenStack software bits (for which we should continue to use project teams) or directly related to a specific governance body (for which we should continue to use "working groups"). SIGs are especially good when the activity is centered around a topic or practice that spans all our community (developers, operators, end users...), forming a guild of people with a shared interest. Security IMHO is a great example of such a topic. The Security team's raison-d'être is the production of software, but more generally the improvement of the state of security in all aspects of OpenStack. It can gather all security-conscious people in all our community. So I think the Security project team would benefit from becoming a proper SIG. You might say, but it also produces software (anchor, bandit, syntribos...). You would be right, but (1) SIGs can totally have software by-products and own git repositories, and (2) that software is more about security in general than a piece of OpenStack itself. You might wonder, will that result in losing ATC status (TC voting rights) ? Well no, the plan being to consider SIGs in the same way as project teams as far as voting rights are concerned. What do you think ? -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, October 27th
of people for which English is not the primary language, the Technical Committee dropped its dependency on weekly meetings. So that you can still get hold of TC members on IRC, we instituted a series of office hours on #openstack-tc: * 09:00 UTC on Tuesdays * 01:00 UTC on Wednesdays * 15:00 UTC on Thursdays For the coming week, I expect the main topic of discussion to be Summit preparations ! == Skipping next two status updates == Due to travel and low expected activity on the governance repository front during summit, I'll be skipping the next two reports. The next one shall be published on Friday, November 17. Cheers, -- Thierry Carrez (ttx) __ 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
[openstack-dev] [all] Book the date: next PTG will be in Dublin, week of Feb 26, 2018
Hi everyone, In case you missed the news last week, it's now confirmed: the next PTG will happen in Dublin (Ireland), the week of February 26, 2018. We are still working on locking down the exact location, so please stay tuned for more details. But you can already mark this date and location in your calendars. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all] [elections] Technical Committee Election Results
Tony Breeds wrote: > On Wed, Oct 25, 2017 at 10:06:46PM -0400, David Moreau Simard wrote: >> Was it just me or did the "official" period for campaigning/questions was >> awfully short ? >> >> The schedule [1] went: >> TC Campaigning: (Start) Oct 11, 2017 23:59 UTC (End) Oct 14, 2017 23:45 >> UTC > > The original was: > - name: 'TC Campaigning' > start: '2017-10-09T23:59' > end: '2017-10-12T23:45' > > but that needed to be adjusted (https://review.openstack.org/509654/) > > While that was still the same duration it was mid-week. > >> That's three days, one of which was a saturday. >> Was it always this short ? It seems to me that this is not a lot of time to >> the community to ask (read, and answer) thoughful questions. There used to be no campaigning period at all, so it had been shorter :) >> I realize this doesn't mean you can't keep asking questions once the actual >> election voting start but I wonder if we should cut a few days from the >> nomination and give it to the campaigning. > > I can't find anything that documents how long the nomination period > needed to be, perhaps I missed it? So we could do this but it's already > quite short. So more likely we could just extend the Campaigning period > if that's the consensus. Duration of campaigning period is not mandated by the TC charter, so left at the appreciation of election officials. > The whole election takes close to 3 weeks of officials time so I'd like > to ask we be mindful of that before we extend things too much It's clearly a balance between having interesting discussions and triggering election fatigue. I'd say we need to have /some/ campaigning time but not too much :) Ideally discussions would start once people self-nominate, and we could keep the period between nomination close and election start relatively short (3/4 business days max). -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates
Doug Hellmann wrote: > [...] > It feels like we have two related by not necessarily dependent > policy questions we need to answer before we decide how to proceed: I don't have strong opinions on any of those two, I think anything would work. If I had to pick between yes and no, here is my gut feeling: > (a) Do we want to move the release job definitions from project-config > and openstack-zuul-jobs to the releases repo? Leaning towards yes as it will (imho) simplify maintenance. We'll still have a couple of privileged jobs that will live on the infra side though? > (b) Do we want to have multiple release job templates due to custom > dependencies (or any other reason)? Leaning towards no if we can avoid it, again to simplify operations. That said, it will be difficult to enforce... -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all] [elections] Technical Committee Election Results
Tony Breeds wrote: > On Mon, Oct 23, 2017 at 09:35:34AM +0100, Jean-Philippe Evrard wrote: > >> I agree, we should care about not repeating this Pike trend. It looks >> like Queens is better in terms of turnout (see the amazing positive >> delta!). However, I can't help but noticing that the trend for >> turnouts is slowly reducing (excluding some outliers) since the >> beginning of these stats. > > Yup, the table makes that pretty visible. > >> Any idea on how to improve that? One facet of this trends may not be negative: As we make it more and more clear that TC activity is more about duties than about rights (more about stewardship then leadership), people care a bit less about specific individuals and are less motivated by the vote itself. If the activity of the TC was a lot more conflict and a lot less consensus (as it used to be in the past) then I think people would care more about representation of their interests and who exactly ends up being elected. -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?
Colleen Murphy wrote: > On Sat, Oct 21, 2017 at 9:00 AM, Diana Clarke > mailto:diana.joan.cla...@gmail.com>> wrote: > > Congrats on being elected to the TC, Colleen! > > You mentioned earlier in this thread that, "a major problem in the > tech world is not just attracting underrepresented contributors, but > retaining them". > > I'm curious if the TC has considered polling the people that have left > OpenStack for their experiences on this front. > > Something along the lines of: > > "I see you contributed 20 patches in the last cycle, but haven't > contributed recently, why did you stop contributing?". > > Given the recent layoffs, I suspect many of the responses will be > predicable, but you might find some worthwhile nuggets there > nonetheless. > > I'm not aware of such an initiative so far but I do think it would be > useful, and perhaps something we can partner with the foundation on. Kind of parallel to the polling idea: John Dickinson has some interesting scripts that he runs to detect deviation from a past contribution pattern (like someone who used to contribute a few patches per cycle but did not contribute anything over the past cycle, or someone who used to contribute a handful of patches per month who did not send a single patch over the past month). Once oddities in the contribution pattern are detected, he would contact the person to ask if anything happened or changed that made them stop contributing. John would probably describe it better than I did. I like that it's not just quantitative but more around deviation from an established contribution pattern, which lets him spot issues earlier. Note that this sort of analysis works well when combined with personal outreach, which works better at project team level... If done at OpenStack level you would likely have more difficulty making it feel personal (if I end up reaching out to a Tacker dev that stopped contributing, it won't be as effective as if the Tacker PTL did the outreach). One thing we could do would be to productize those tools and make them available to a wider number of people. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, October 20th
Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of all open topics (updated twice a week) at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker If you are working on something (or plan to work on something) that is not on the tracker, feel free to add to it ! == TC Election still in progress == A few hours left to vote! Note that your ballot email might have been classified as spam. == Recently-approved changes == * New project team: OpenStack-Helm (helm charts for OpenStack) [1] * Remove tox from PTI for python tarballs [2] * Goal updates: kolla, ironic * Retired repos: pylockfile * New repos: contributor-guide, heat-dashboard, senlin-tempest-plugin [1] https://review.openstack.org/#/c/500118/ [2] https://review.openstack.org/#/c/508693/ The most significant change this week is the officialization of the "OpenStack-Helm" project team, a packaging team working on producing Helm charts to deploy OpenStack using helm. This likely closes the list of OpenStack project teams for the Queens cycle. The Glare team application, in particular, was deferred to Rocky by its PTL. == Under review == Our latest top-5 "help wanted" list proposed addition, "champions and stewards" is still pretty much under review: https://review.openstack.org/#/c/510656/ Monty's series of modifications to the PTI (project testing interface) still had two open changes. Please review at: * https://review.openstack.org/#/c/508694/ * https://review.openstack.org/#/c/509868/ == TC member actions for the coming week(s) == Monty should answer the feedback on the supported database version resolution (https://review.openstack.org/493932) so that we can make progress there -- or abandon it. == Office hours == To be more inclusive of all timezones and more mindful of people for which English is not the primary language, the Technical Committee dropped its dependency on weekly meetings. So that you can still get hold of TC members on IRC, we instituted a series of office hours on #openstack-tc: * 09:00 UTC on Tuesdays * 01:00 UTC on Wednesdays * 15:00 UTC on Thursdays For the coming week, I expect the main topic of discussion to be the onboarding of the newly-elected membership, as well as Summit preparations. Cheers, -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
Emilien Macchi wrote: > > Thierry, when I read your comment on Gerrit I understand you prefer to > amend the existing policy and just make a note for installers (which > is I think the option #2 that I proposed). Can you please confirm > that? > So far I see option #1 has large consensus here, I'll wait for > Thierry's answer to continue to work on it. Sorry I wasn't clear. I started working on tag modifications (to add ACL requirements and make it more clearly main-service-specific) when I realized it was just merely pointing to stable policy. Reading your proposed change it appeared as two variants on the same document... So I figured we could spare the creation of an additional tag. I'm fine with either approach really (solution 1 or solution 2). The important part is to define the variant/other policy in a way that would work for most deployment teams while benefiting the users interested in stability (i.e. a good trade-off between getting desirable fixes and being exposed to unnecessary risk). -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc] Technical Committee Status update, October 13th
Thierry Carrez wrote: > == Final call on votes == > > We need to make a final call on the Glare project team application for > the Queens cycle. If by the end of day (AOE) on Monday there is no > majority support for it, the application will be denied. So please jump > on that review if you haven't yet: > > https://review.openstack.org/479285 I realize I wasn't clear here... This will be decided following the charter rules[1], so with 5 votes in favor and 4 votes against (the current status), this will be approved. In all cases I'll let the 3-day grace period after we come to a decision here to let everyone else weigh in. [1] https://governance.openstack.org/tc/reference/charter.html#motions -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
Emilien Macchi wrote: > [...] > ## Proposal > > Proposal 1: create a new policy that fits for projects like installers. > I kicked-off something here: https://review.openstack.org/#/c/511968/ > (open for feedback). > Content can be read here: > http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases > Tag created here: https://review.openstack.org/#/c/511969/ (same, > please review). > > The idea is really to not touch the current stable policy and create a > new one, more "relax" that suits well for projects like installers. > > Proposal 2: change the current policy and be more relax for projects > like installers. > I haven't worked on this proposal while it was something I was > considering doing first, because I realized it could bring confusion > in which projects actually follow the real stable policy and the ones > who have exceptions. > That's why I thought having a dedicated tag would help to separate them. > > Proposal 3: no change anywhere, projects like installer can't claim > stability etiquette (not my best option in my opinion). > > Anyway, feedback is welcome, I'm now listening. If you work on Kolla, > TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has > this need), please get involved in the review process. My preference goes to proposal 1, however rather than call it "relaxed" I would make it specific to deployment/lifecycle or cycle-trailing projects. Ideally this policy could get adopted by any such project. The discussion started on the review and it's going well, so let's see where it goes :) -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, October 13th
Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of all open topics (updated twice a week) at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker If you are working on something (or plan to work on something) that is not on the tracker, feel free to add to it ! == TC Election in progress == We are renewing 6 of the 13 TC seats. The nominations period is now ended, you can find the full list of candidates at: https://governance.openstack.org/election/ The vote will start early Sunday and be open until EOD Friday. You're encouraged to send your questions to the candidates before voting opens, so that you can learn more about the candidates and their vision for OpenStack. After that, don't forget to vote next week! == Recently-approved changes == * New project team: Masakari (Instances High Availability Service) [1] * Add Designate to the top 5 help wanted. [2] * Adjustments to Infra contributors top-5 entry [3] * Add the supports-accessible-upgrade tag to Nova and Cinder [4] * Remove assert:supports-zero-impact-upgrade tag [5] * Align CTI to PTI [6] * Goal updates: zun * New repos: ansible-hardening, python-tempestconf, manila-tempest-plugin, magnum-tempest-plugin [1] https://review.openstack.org/#/c/500118/ [2] https://review.openstack.org/504217 [3] https://review.openstack.org/#/c/507637/ [4] https://review.openstack.org/509170 [5] https://review.openstack.org/506241 [6] https://review.openstack.org/508692 Beyond the adoption of a new project team (Masakari), the most visible changes in this busy week or on the Top-5 "help wanted" list (addition of Designate, reordering and adding details to the "Infra sysadmins" entry). You can find list here: https://governance.openstack.org/tc/reference/top-5-help-wanted.html (refresh pending post-job in progress) == Final call on votes == We need to make a final call on the Glare project team application for the Queens cycle. If by the end of day (AOE) on Monday there is no majority support for it, the application will be denied. So please jump on that review if you haven't yet: https://review.openstack.org/479285 == Under review == Doug proposed a last item for our top-5 "help wanted" list: "champions and stewards". Please review it at: https://review.openstack.org/#/c/510656/ A new "OpenStck-Helm" packaging project team (producing Helm charts), filed for official recognition as an OpenStack team. Please review their application at: https://review.openstack.org/#/c/511320/ Monty posted a series of modifications to the PTI (project testing interface). Please review at: * https://review.openstack.org/#/c/508693/ * https://review.openstack.org/#/c/508694/ * https://review.openstack.org/#/c/509868/ == TC member actions for the coming week(s) == Monty should answer the feedback on the supported database version resolution (https://review.openstack.org/493932) so that we can make progress there. John should review Lance's response to his objection on: https://review.openstack.org/#/c/500985/ == Office hours == To be more inclusive of all timezones and more mindful of people for which English is not the primary language, the Technical Committee dropped its dependency on weekly meetings. So that you can still get hold of TC members on IRC, we instituted a series of office hours on #openstack-tc: * 09:00 UTC on Tuesdays * 01:00 UTC on Wednesdays * 15:00 UTC on Thursdays For the coming week, I expect the main topic of discussion to be the ongoing elections, as well as iterations on the exact wording for the "champions and stewards" top-5 item. Cheers, -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [forum] Draft Schedule - Deadline Oct 13 Friday 20:00 UTC
Mike Perez wrote: > [...] > You have until Friday, October 13th 20:00UTC to let us know of any > corrections/conflicts. Nice work, all! A few potential conflicts I detected that we might want to address: 11/8 11:00-11:40 I know a number of people who will want to attend both the "Ironic vs. Mogan vs. Nova" discussion and the "First contact SIG" discussion. I suggest swapping "First Contact SIG" with the "Heat ops and users feedback" session later on the same day. 11/7 11:40-12:20 In the same vein, I know of a few people interested in both the "Documentation and relnotes" session and the "Making OpenStack more palatable to part-time contributors" session. I suggest swapping the "part-time contributors" discussion with the "Users / Operators adoption of QA tools / plugins" session earlier on the same day (bonus point for eliminating the QA/Zuul session conflict there). Cheers, -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [tc][election] TC non-candidacy
Monty Taylor wrote: > I have decided not to seek reelection for the TC. Thanks for all your insights and guidance during all those years. Please continue to scream and let us know whenever we are doing anything crazy! -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, October 6th
Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of all open topics (updated twice a week) at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker If you are working on something (or plan to work on something) that is not on the tracker, feel free to add to it ! == Election period started == We are renewing 6 of the 13 TC seats, nominations are open until EOD Tuesday, October 10. If you are interested in open source project governance and want to help continuously adapting it to an ever-evolving environment, please consider running ! https://governance.openstack.org/election/ == Recently-approved changes == * Adopt python-openstacksdk into shade project [1] * Remove stable:follows-policy tag from TripleO [2] * Add api interop assert tag to nova [3] [1] https://review.openstack.org/#/c/501426/ [2] https://review.openstack.org/#/c/507924/ [3] https://review.openstack.org/#/c/506255/ A bit of additional context about the first two changes: While the name was implying otherwise, python-openstacksdk never was the one official OpenStack Python SDK. To present a less confusing, more usable and more complementary face to end users of OpenStack clouds, the Shade project team (with the help of the OpenStackClient team) proposed to adopt the now semi-abandoned python-openstacksdk and work to refactor the 3 projects to avoid overlap and increase complementarity. Deployment projects like TripleO have needs and policies around stable branches that are different from classic service projects, which make the current stable:follows-policy tag difficult to follow, so they asked to have the tag removed. This may point to a need for a specific common stable policy for deployment/lifecycle management projects. == Voting in progress == Masakari, a new project to cover Virtual Machine HA needs, reached majority support and will be approved next Tuesday unless last-minutes objections are posted: https://review.openstack.org/#/c/500118/ fungi's change moving the "Infra sysadmins" entry in the top-5 help wanted list to #2 also reached majority and will be approved next Tuesday unless someone objects: https://review.openstack.org/#/c/507637/ smcginnis's proposal to get rid of (unused) supports-zero-impact-upgrade is still missing a couple of votes to pass: https://review.openstack.org/#/c/506241/ == Open discussion == The supports-accessible-upgrade is also being considered for removal, since the amount of information it conveys is questionable. Alternatives are being discussed on the mailing-list. Join on the review or the thread: * https://review.openstack.org/#/c/506263/ * http://lists.openstack.org/pipermail/openstack-dev/2017-October/123061.html Monty posted new patchsets on his proposed updates around the project testing interface. Please review at: * https://review.openstack.org/#/c/508693/ * https://review.openstack.org/#/c/508694/ 3 other new project teams are still being actively discussed, with no clear consensus yet. Please join the discussion if you have an opinion on whether they should be made official OpenStack project teams: * Glare (https://review.openstack.org/479285) * Stackube (https://review.openstack.org/#/c/462460/) * Mogan (https://review.openstack.org/#/c/508400/) == TC member actions for the coming week(s) == Monty should answer the feedback on the supported database version resolution (https://review.openstack.org/493932) so that we can make progress there. John should review Lance's response to his objection on: https://review.openstack.org/#/c/500985/ Doug and Thierry will draft a top-5 help wanted list addition around 'champions' or leaders of various efforts, as Lance and Chandan prove it to be a successful way of getting cross-project work done. == Need for a TC meeting next Tuesday == Nothing is blocked to the point of requiring a specific meeting. Expect the election season and the last project team applications to be the main topics discussed during TC office hours next week. You can find TC office hours at: https://governance.openstack.org/tc/#office-hours Cheers, -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [ptl][tc] Accessible upgrade support
Sean Dague wrote: > [...] > I still think it's hard to describe to folks what is going on without > pictures. And the tag structure might just be the wrong way to describe > the world, because they are a set of positive assertions, and upgrade > expectations are really about: "how terrible will this be". > > If I was an operator the questions I might have is: > [...] > > The tags were really built around grouping a few of these, but even with > folks that are near the problem, they got confusing quick. I really > think that some more pictoral upgrade safety cards or something > explaining the things you need to consider, and what parts projects > handle for you would be really useful. And then revisit whatever the > tagging structure is going to be later. Good point. Maybe the upgrade functionality is critical enough to warrant its own data set, and using a set of binary tags is not the best way to capture it. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [ptl][tc] Accessible upgrade support
Graham Hayes wrote: > On Thu, 5 Oct 2017, at 09:50, Thierry Carrez wrote: >> [...] >> In particular, we created two paths in the graph: >> * upgrade < accessible-upgrade >> * upgrade < rolling-upgrade < zero-downtime < zero-impact >> >> I personally would get rid of zero-impact (not sure there is that much >> additional information it conveys beyond zero-downtime). >> >> If we could make the requirements of accessible-upgrade a part of >> rolling-upgrade, that would also help (single path in the graph, only 3 >> "levels"). Is there any of the current rolling-upgrade things (cinder, >> neutron, nova, swift) that would not qualify for accessible-upgrade as >> well ? > > Well, there is projects (like designate) that qualify for accessible > upgrade, but not rolling upgrade. Sure, but is there real user value in communicating that capability separately from the rolling-upgrade ability ? And if there is value, is it enough to justify creating a harder-to-decipher upgrade tag landscape ? The fact that you didn't apply for the tag yet points to the limited value of it... -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [ptl][tc] Accessible upgrade support
Matt Riedemann wrote: > What's the difference between this tag and the zero-impact-upgrades tag? > I guess the accessible one is, can a user still ssh into their VM while > the nova compute service is being upgraded. The zero-impact-upgrade one > is more to do with performance degradation during an upgrade. I'm not > entirely sure what that might look like, probably need operator input. > For example, while upgrading, you're live migrating VMs all over the > place which is putting extra strain on the network. The zero-impact-upgrade tag means no API downtime and no measurable impact on performance, while the accessible-upgrade means that while there can be API downtime, the resources provisioned are still accessible (you can use the VM even if nova-api is down). I still think we have too many of those upgrade tags, and amount of information they provide does not compensate the confusion they create. If you're not clear on what they mean, imagine a new user looking at the Software Navigator... In particular, we created two paths in the graph: * upgrade < accessible-upgrade * upgrade < rolling-upgrade < zero-downtime < zero-impact I personally would get rid of zero-impact (not sure there is that much additional information it conveys beyond zero-downtime). If we could make the requirements of accessible-upgrade a part of rolling-upgrade, that would also help (single path in the graph, only 3 "levels"). Is there any of the current rolling-upgrade things (cinder, neutron, nova, swift) that would not qualify for accessible-upgrade as well ? -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc] [election] NON nomination for TC
Sean Dague wrote: > I'd like to announce that after 4 years serving on the OpenStack > Technical Committee, I will not be running in this fall's > election. Over the last 4 years we've navigated some rough seas > together, including the transition to more inclusion of projects, the > dive off the hype curve, the emergence of real interoperability > between clouds, and the beginnings of a new vision of OpenStack > pairing with more technologies beyond our community. > > There remains a ton of good work to be done. But it's also important > that we have a wide range of leaders to do that. Those opportunities > only exist if we make space for new leaders to emerge. Rotational > leadership is part of what makes OpenStack great, and is part of what > will ensure that this community lasts far beyond any individuals > within it. > > I plan to still be around in the community, and contribute where > needed. So this is not farewell. However it will be good to see new > faces among the folks leading the next steps in the community. > > I would encourage all members of the community that are interested in > contributing to the future of OpenStack to step forward and run. It's > important to realize what the TC is and can be. This remains a > community driven by consensus, and the TC reflects that. Being a > member of the TC does raise your community visibility, but it does not > replace the need to listen, understand, communicate clearly, and > realize that hard work comes through compromise. > > Good luck to all our candidates this fall, and thanks for letting me > represent you the past 4 years. Thanks Sean for your service on the TC. Your experience and knowledge of open source development dynamics will be missed ! I really appreciated your insights and grounded perspective in difficult governance discussions that we had to navigate together. I hope you'll still be able to weigh in on some of those, even if you won't participate in formal votes anymore. Cheers, -- Thierry Carrez (ttx) __ 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
[openstack-dev] [all] Report on TC activity for the May-Oct 2017 membership
Hi everyone, The election process to renew 6 of our Technical Committee members was started[1], with the self-nomination period running this week. Information on what the Technical Committee is and what it does is generally available on the governance website[2]. However you may wonder what the current Technical Committee membership achieved (to this day) since its election in May. If so, read on! During that period the TC made a number of decisions and passed a number of resolutions to shape the future of OpenStack. One of them is the publication of a top "help wanted" list to more clearly communicate where our community is struggling and where extra contributions can really make a difference. That list is now published with entries for "doc owners", "infra sysadmins", and "Glance contributors" (and more coming up). Another area is adapting to changes in our ecosystem: we added etcd as an OpenStack base service to encourage all projects to take advantage of etcd for coordination. We also passed guidelines for managing releases of binary artifacts, which can be applied to Go executables or Docker images. We evolved our project team list, removing Fuel and more recently adding Blazar and Cyborg. Other policies and clarifications adopted by the current membership included a clarification about the current state of PostgreSQL in OpenStack, a description of what upstream supports means, the addition of a "assert:supports-api-interoperability" tag, and selecting community goals for the Queens release cycle. But perhaps the work the most relevant for the long term was the publication of the TC 2019 vision, painting a picture of a desirable future for the Technical Committee and by extension for the OpenStack community. One of the areas defined in this vision was to achieve better community diversity and inclusivity. To achieve geographical diversity (and in particular better tap into the potential contributors in China) we need to be less reliant on regular synchronous team meetings on IRC. The TC decided to lead by example there and drop its traditional reliance on weekly meetings to make progress. Most of the work is now done asynchronously, and we transitioned our IRC public presence to "office hours" in various timezones in a dedicated channel (#openstack-tc). We also passed resolutions to stop *requiring* IRC meetings for project teams (and allow them to host meetings in any logged IRC channel). Community diversity is also about engaging people coming from an OpenStack operator background to be more directly involved with upstream development. TC and UC members collaborated to create a new form of workgroups (called SIGs) that should help in eliminating artificial barriers to contribution and organize everyone around common topics of interest. Another area in the vision is how we engage with adjacent communities. Members of the TC are actively engaged in reaching out and sharing experiences, in particular with the Kubernetes and the Ansible communities. But there are areas in the vision where the TC needs to make progress in the near future, in particular the definition of "constellations", and growing the next generation of OpenStack leaders. If you're interested in helping, please throw your name in the hat ! The Technical Committee is just a bunch of humans interested in the welfare of OpenStack as a whole. The activity of the TC also doesn't stop with elected members: you can help, draft, propose, and discuss changes without being formally elected. Join us on #openstack-tc ! [1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/122942.html [2] https://governance.openstack.org/tc/ -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
OK, I got individual PTL confirmation that it was OK to remove all of those from PyPI: mistral-extra 2015.1.0 mistral-dashboard 2015.1.* networking-odl, 2015.1.1 2015.1.dev986 networking-midonet, 2014.2.2 and various 2015.1.* versions (might have been removed by networking-midonet folks by now) sahara-image-elements 2014.*.* sahara-dashboard 2014.*.* Cheers, -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, September 29th
Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of all open topics (updated twice a week) at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker If you are working on something (or plan to work on something) that is not on the tracker, feel free to add to it ! == Recently-approved changes == NB: Some changes (marked with ** below) have not formally merged yet at the time of this email due to some jobs stuck in the Zuulv3 transition, but they have been approved nevertheless. * New project team: Blazar (Resource Reservation Service) [1] * New project team: Cyborg (Accelerator Lifecycle Management) [2] ** * Put searchlight into maintenance mode [3] ** * Adding "Infra sysadmins" to help-wanted list [4] * Update wording in Glance "help-wanted" item [5] * Updates to Queens goals status [1] https://review.openstack.org/#/c/482860/ [2] https://review.openstack.org/#/c/504940/ [3] https://review.openstack.org/#/c/502849/ [4] https://review.openstack.org/#/c/502259/ [5] https://review.openstack.org/#/c/503168/ Lots of change this week, with the adoption of two new project teams to the OpenStack family: Blazar (Resource Reservation Service), and Cyborg (Accelerator Lifecycle Management). Searchlight was placed in maintenance-mode: lower activity is expected as it is essentially feature-complete and functional, just needs more projects to implement plugins. Our infrastructure team was pretty busy this week with the migration to Zuul v3, but they are still struggling with resources and timezone coverage. To reflect the constant need for more resources there, it was added to the "Top 5" help-wanted list: https://governance.openstack.org/tc/reference/top-5-help-wanted.html == New project teams == We still have 3 project teams still applying for inclusion. Stackube (https://review.openstack.org/#/c/462460/) voting is in progress. They provided extra information on the commit message, which pointed to a few necessary actions (like holding their meeting in publicly-logged IRC channels, or more active cooperation with the Kuryr folks). Glare (https://review.openstack.org/479285) application is still under heavy discussion. While Glare has pledged a narrower scope and coexistence with Glance lately, most TC members would like to let some time pass before approving the team. Masakari (https://review.openstack.org/#/c/500118/) voting is in progress, no objection recorded so far. == An update on SIGs == SIGs are a new form of workgroups, more explicitly operating beyond governance boundaries and open to anyone interested in improving the state of OpenStack on a specific topic. We now have 3 active SIGs (Meta, API and Scientific), and 4 are being formed as we speak (Ansible, K8s, Public Cloud, Self-healing). We'll continue on-boarding new SIGs in the coming weeks, but the Meta SIG will also discuss the next steps: active promotion of existing SIGs as a way to contribute to OpenStack, setting up a governance website around SIGs to replace the current wiki page, setting clearer expectations in terms of regular status reports, etc. Join us on the openstack-sigs ML if interested: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs == Tag changes == smcginnis proposal to remove assert:supports-zero-impact-upgrade did not meet serious objection yet. Please review it at: https://review.openstack.org/506241 The removal of assert:supports-accessible-upgrade is under discussion though, as some projects could just claim it now. So if this tag provides a useful piece of information (and projects apply to it), it should probably be kept around: https://review.openstack.org/506263 A number of tag applications were proposed and could use some review attention: * supports-rolling-upgrade for Heat: https://review.openstack.org/503145 * api-interop assert for Nova: https://review.openstack.org/506255 * api-interop assert for Ironic: https://review.openstack.org/482759 * Remove stable:follows-policy for TripleO: https://review.openstack.org/507924 == Voting in progress == A new patchset was posted for adding Designate to the top-5 help wanted list. It's now ready for vote pile-up: https://review.openstack.org/498719 fungi proposed to make Infra contributors #2 in the list, please vote here: https://review.openstack.org/#/c/507637/ == TC member actions for the coming week(s) == Monty should answer the feedback on the supported database version resolution (https://review.openstack.org/493932) so that we can make progress there. == Need for a TC meeting next Tuesday == The Glare application is where there is the standing disagreement at this point, but the discussion seems to still make progress on the review and during office hours. I propose we give it another week before calling a more formal meeting to discuss this. You can find TC office hours at: https://governance.openstack.org/tc/#office
[openstack-dev] [all][swg] Status of the Stewardship WG
Hi everyone, In Denver we had a room for the TC and the Stewardship working group, where we discussed the current state of the Stewardship WG. I took the action to write a follow-up thread to communicate the group status. The Stewardship working group was created after the first session of leadership training that TC/UC/Board and other community members were invited to participate in in 2016. The idea was to follow-up on what we learned at ZingTrain and push adoption of the tools we discovered there. While we did (and do continue to) apply what we learned there, the activity of the workgroup mostly died when we decided to experiment getting rid of weekly meetings (for greater inclusion) and Colette could no longer dedicate time leading the workgroup. It's proven possible to have workgroups without regular meetings, but you need to replace them with continuous status updates, which are difficult to produce without team leaders. Currently the workgroup is dormant, until someone steps up to lead it again. If we resurrected it, we'd likely use the new SIG format, as there is no reason that the Stewardship activities should be solely under the Technical Committee governance. Join us on penstack-swg if interested ! Regards, -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [Openstack-operators] [tc][nova][ironic][mogan] Evaluate Mogan project
Erik McCormick wrote: > [...] > Also, if you'd like to discuss this in detail with a room full of > bodies, I suggest proposing a session for the Forum in Sydney. If some > of the contributors will be there, it would be a good opportunity for > you to get feedback. Yes, "Bare metal as a service: Ironic vs. Mogan vs. Nova" would make a great topic for discussion in Sydney, assuming Zhenguo is able to make the trip... Discussing the user need on one side, and how to best integrate with the existing pieces on the other side would really help starting this on the right foot. Zhenguo: if you plan to be present, could you suggest this topic for discussion at: http://forumtopics.openstack.org/ Deadline is tomorrow :) -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] Forum Reminder! Submissions due by Sept 29th
Miguel Lavalle wrote: > Is this the link we are supposed to use: > http://forumtopics.openstack.org/cfp/create Yes. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, September 22nd
Hi! This is the weekly update on Technical Committee initiatives. Following feedback at the PTG, I moved the full list of all open topics to a new wiki page. Update your bookmarks to: https://wiki.openstack.org/wiki/Technical_Committee_Tracker If you are working on something (or plan to work on something) that is not on the tracker, feel free to add to it. == Recently-approved changes == * Drop Technical Committee weekly meetings [1] * Updating the documentation team mission statement [2] * Update team diversity tags [3] * Confirm change of Neutron PTL to Miguel Lavalle [4] * Confirm change of Trove PTL to Manoj Kumar [5] * Add stestr to python unit test runner cti [6] * New repositories: monasca-specs, whereto, zun-tempest-plugin, murano-tempest-plugin, zaqar-tempest-plugin, neutron-tempest-plugin * Updates to policy-in-code and split-tempest-plugins goals status * Doc links updates: zun [1] https://review.openstack.org/#/c/459848/ [2] https://review.openstack.org/#/c/499556/ [3] https://review.openstack.org/#/c/500830/ [4] https://review.openstack.org/#/c/502308/ [5] https://review.openstack.org/#/c/503786/ [6] https://review.openstack.org/#/c/503447/ Main change is the confirmation in writing that the TC will rely more on asynchronous communications in its decision-making process. For direct communications, we hold office hours at various times during the week. Official meetings should therefore be exceptional at this point. Read the full resolution for more details: https://governance.openstack.org/tc/resolutions/20170425-drop-tc-weekly-meetings.html == PTG report == The TC shared a room at the PTG on Monday/Tuesday with the Stewardship WG, then met again on Friday afternoon. You can find notes at: https://etherpad.openstack.org/p/queens-PTG-TC-SWG == New project teams == We now have 5 project teams applying for inclusion. Ideally those applications should be approved or rejected before the Queens-1 milestone (mid-October), but we are still missing input from several TC members. Blazar (https://review.openstack.org/482860) reached majority on Sept 20, will be approved on Sept. 26 unless new objections are raised. Glare (https://review.openstack.org/479285) is still being discussed, with several TC members voicing a preference for reconsidering this application in 6 months to give the Glance/Glare relationship more time to mature. Stackube (https://review.openstack.org/#/c/462460/) voting is in progress, with likely another patchset needed to include missing information regarding requirements. Masakari (https://review.openstack.org/#/c/500118/) voting is in progress, no objection recorded so far. Cyborg (https://review.openstack.org/#/c/504940/) voting is in progress, no objection recorded so far. == Open discussions == Following a PTG discussion, smcginnis proposed to remove upgrade assert tags that do not have a single deliverable applying for them: * supports-zero-impact-upgrade: https://review.openstack.org/506241 * supports-accessible-upgrade: https://review.openstack.org/506263 The top-5 help wanted entry for Designate contributors is still being discussed, and likely to require another revision. Please review it here: https://review.openstack.org/498719 Trove moving to maintenance-mode is still being discussed, with input from the newly-chosen PTL wanted: https://review.openstack.org/#/c/488947/ Finally there are a number of non-trivial tag applications that you may want to review: * supports-rolling-upgrade for Heat: https://review.openstack.org/503145 * api-interop assert for Nova: https://review.openstack.org/506255 * api-interop assert for Ironic: https://review.openstack.org/482759 == Voting in progress == Infrastructure sysadmins top-5 addition (https://review.openstack.org/496404) now reached majority support and will be approved on Sept 26 pending objections. The Glance top-5 entry is being reworded to account for the recent activity: https://review.openstack.org/#/c/503168/ -- this also reached majority on Sept 20 and will be approved on Sept 26 unless new objections are recorded. Searchlight moving to maintenance-mode eached majority support today and will be approved on Sept 26 pending objections: https://review.openstack.org/#/c/502849/ == TC member actions for the coming week(s) == Monty should answer the feedback on the supported database version resolution (https://review.openstack.org/493932) so that we can make progress there. John's should convert his global inclusion resolution (https://review.openstack.org/#/c/460946/) into project-team-guide material. == Need for a TC meeting next Tuesday == No proposal is really blocked due to member disagreement right now. Nothing really requires holding an official meeting, so let's discuss active proposals during the TC office hours next week. You can join us at: https://governance.openstack.org/tc/#office-hours Cheers, -- Thierry C
Re: [openstack-dev] [skip-level-upgrades][fast-forward-upgrades] PTG summary
Sean Dague wrote: > Agreed. We're already at 5 upgrade tags now? > > I think honestly we're going to need a picture to explain the > differences between them. Based on the confusion that kept seeming to > come during discussions at the PTG, I think we need to circle around and > figure out if there are different ways to explain this to have greater > clarity. In the TC/SWG room we reviewed the tags, and someone suggested that any tag that doesn't even have one project to apply it to should probably be removed. That would get us rid of 3 of them: supports-accessible-upgrade, supports-zero-downtime-upgrade, and supports-zero-impact-upgrade (+ supports-api-interoperability which has had little support so far). They can always be resurrected when a project reaches new heights? -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Jeremy Stanley wrote: > On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote: > [...] >> Yes, for a first batch I propose we clean up the following: >> >> python-congressclient 2015.1.0 >> python-congressclient 2015.1.0rc1 >> python-designateclient 2013.1.a8.g3a2a320 >> networking-hyperv 2015.1.0 > [...] > > Are we waiting for any confirmation on this, or does a week of > silence constitute tacit approval? Should I go ahead and delete > these from PyPI now? Yes please. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [oslo][oslo.db][keystone] A POC of Keystone over CockroachDB
Ronan-Alexandre Cherrueau wrote: > Hi folks, > > Recently in the Inria's Discovery initiative[1], we got in touch with > CockroachLabs guys with an idea: make Keystone supports CockorachDB. So > we give it a try and you can find a very first result on our GitHub[2]. > The GitHub project consists of a Vagrant file that spawns a VM with a > CockroachDB database and then installs Keystone with Devstack using > CockroachDB as backend. > > CockroachDB claims to support the PostgreSQL protocol. It also provides > support for SQLAlchemy that mostly inherits from the PostgreSQL one. So, > making Keystone working with CockroachDB should be easy peasy right? > Almost! The rest of this email describes what we have done, to make it > works. > [...] Thanks Ronan-Alexandre for the update! Great to see some progress in the experimentation there. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [ptg] Denver City Guide
To Denver locals and PTG attendees: In case you missed it, there is a wiki page with suggestions of bars, group-friendly dining places and other things to do in Denver that was started at: https://wiki.openstack.org/wiki/PTG/Queens/CityGuide It definitely could use some more material, as teams have started looking into organizing dinners and all. So if you've done some research of your own, or if you're local and know places, please add to the wiki! Also quick reminder that the PTG registration prices are going up in a few hours, so if you haven't registered yet, you should do so now to avoid the stragglers tax ! Cheers, -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, September 1st
Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Allow teams to host meetings in their channels [1][2] * PTL updates following the Queens elections [3][4] * Amend leaderless program resolution timeframe [5] * Docs URL updates [6] * Pike goals updates: ironic * New repositories: solum-tempest-plugin * Retired repositories: oslo-incubator [1] https://review.openstack.org/#/c/485117/ [2] https://review.openstack.org/#/c/495886/ [3] https://review.openstack.org/#/c/493846/ [4] https://review.openstack.org/#/c/498363/ [5] https://review.openstack.org/#/c/492578/ [6] https://review.openstack.org/#/c/496321/ Mostly administrative updates this week, except the final approval of the resolution allowing teams to host meetings in their own channels: https://governance.openstack.org/tc/resolutions/20170718-allow-scheduling-meetings-on-team-channels.html The irc-meetings framework should be updated to allow such meetings to be scheduled. == PTG prep == We'll have a TC / StewardshipWG room on Monday-Tuesday at the PTG. You can chime in on topics we should cover there on the planning etherpad: https://etherpad.openstack.org/p/queens-PTG-TC-SWG == New project teams == We still have 4 new project teams applications up: Stackube, Glare, Blazar and Gluon. We'll likely meet three of those teams during the PTG, withe Glare and Blazar being likely to be approved really soon now. However the Stackube folks are not likely to be present, so it would be great to give that review some extra attention now, so that we can make progress: https://review.openstack.org/462460 == Open discussions == Chris and John both suggested additions to the Top-5 list: Reduce Development Complexity: https://review.openstack.org/496404 Service layering: https://review.openstack.org/498719 The discussion so far mostly revolved around whether the top-5 list, originally meant for highly-tactical TC shouts for help in struggling areas, is the right medium for more strategic / long-term ideas. And if not, what would be the right way to express that. Monty's proposal to be explicit about supported database versions is likely to need a new patchset to incorporate the early feedback: https://review.openstack.org/493932 John's resolution on how decisions should be globally inclusive is still mostly blocked, waiting to be converted into project-team-guide material: https://review.openstack.org/#/c/460946/ == Voting in progress == Flavio's resolution on dropping Technical Committee meetings is still missing a couple of votes before it can be approved: https://review.openstack.org/459848 == TC member actions for the coming week(s) == All members should review the PTG room etherpad and add any topic they want to discuss in the room on Monday/Tuesday of the PTG. Jeremy should find time to raise a discussion (and/or file a proposal) around adding Infra to the Top-5 list. Monty should answer the feedback on the supported database version resolution so that we can make progress there. All members should familiarize themselves with the new project teams being proposed for addition and comment on their reviews (or prepare questions for in-person discussions). == Need for a TC meeting next Tuesday == No proposal is really blocked due to member disagreement at this stage, most are caught in the post-release pre-PTG hiatus. With the PTG coming up the week after, I don't think we need an in-person meeting next week. We should definitely take advantage of the Office Hours[7] for preparatory discussions as we prep for the Board+TC+UC+Staff meeting on Sunday and the PTG week after, though. [7] https://governance.openstack.org/tc/#office-hours Cheers, -- Thierry Carrez (ttx) __ 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
[openstack-dev] [release] Release countdown for week R+1 and R+2, September 4-15
What? A release countdown at R+1 week? Did someone have too many celebratory drinks after Pike release? Well, we are not all done yet. We have release-trailing deliverables to take care of. General Information --- As you probably know, Pike was successfully released[1] on the target date this Wednesday. Projects and libraries following the cycle-with-intermediary model can now propose early Queens releases. However, some deployment-oriented deliverables (from Puppet-OpenStack, Kolla, TripleO...) have opted for a *cycle-trailing* release model, in order to finalize their Pike deliverables *after* the main components are released. Those deliverables should already have published their first release candidates. They can push additional RCs (or last-minute intermediary releases) during the R+1 and R+2 weeks, but need to post their Pike final release before the cycle-trailing release deadline (September 14). [1] http://lists.openstack.org/pipermail/openstack-announce/2017-August/002009.html Upcoming Deadlines & Dates -- Release deadline for cycle-trailing deliverables: September 14 Queens PTG in Denver: Sept 11-15 As usual come find us on #openstack-release IRC channel if you have any questions or concerns. This is the last of the release countdown emails you'll receive from me for Pike. You should soon receive Queens-related communications from our new fearless leader, Sean McGinnis. Thanks again everyone for a great development cycle and a smooth release. Take a step back, look at what you achieved, and be proud. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Claudiu Belu wrote: > So, I believe the general consensus is that the easiest thing to do is to > unpublish the 2015.1.0 version from pypi, with which I also agree. > [...] Yes, for a first batch I propose we clean up the following: python-congressclient 2015.1.0 python-congressclient 2015.1.0rc1 python-designateclient 2013.1.a8.g3a2a320 networking-hyperv 2015.1.0 For the remaining (official) ones (mistral-extra, networking-odl, murano-dashboard, networking-hyperv, networking-midonet, sahara-image-elements, freezer-api, murano-agent, mistral-dashboard, sahara-dashboard) let's wait until we can get PTL signoff. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Tony Breeds wrote: > An extension to this would be to check for other items in the same boat. > I wrote [1] to find anything in the openstack namespace that isn't a > service and has something that looks like a date based release on pypi. > [...] Thanks for computing the list. Unpublishing is a bit of a trade-off -- in the networking-hyperv case the pain resulting from the people using pip to install it (and complaining about the situation) ends up being bigger than the pain of unpublishing it... So I'm not sure we should necessarily proactively unpublish everything in the same boat (especially if nobody asks for it). In particular, we should definitely *not* do it for anything that's not an official OpenStack deliverable. That leaves us with: Official libraries (python-congressclient, python-designateclient) for which I think we should proactively fix them ASAP. Other official things (mistral-extra, networking-odl, murano-dashboard, networking-hyperv, networking-midonet, sahara-image-elements, freezer-api, murano-agent, mistral-dashboard, sahara-dashboard) for which we should fix them if pip is a reasonable way of installing them (after asking the local PTL if that's alright). -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
[openstack-dev] OpenStack Pike is officially released!
Hello OpenStack community, I'm proud and excited to announce the final release for the components of OpenStack Pike, which concludes the 6-month Pike development cycle. You will find a complete list of all components, their latest versions, and links to individual project release notes documents listed on the OpenStack releases site: https://releases.openstack.org/pike/ Congratulations to everyone who has contributed to making this release a success. Pike saw contributions from more than 1800 individuals, bringing the total number of contributors to OpenStack since 2012 up to 6650. During the Pike cycle we merged an average of 220 changes per day, which makes OpenStack one of the most active software development project out there today. Our next development cycle, Queens, has already started. Project team members will meet in Denver starting on September 11 at the Project Teams Gathering to kickstart the work for the coming 6 months. I hope to see you there! Thanks, -- Thierry Carrez (ttx) __ 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
[openstack-dev] [ptg] PTG general info & upcoming registration price hike
Hi everyone, We are only 12 days away from the start of the PTG in Denver. If you haven't registered yet, I encourage you to do so now: early Saturday morning the registration price will increase (stragglers tax). So head now to https://www.openstack.org/ptg and hit that button before it's too late. If you're still wondering what will happen at this PTG (or you went to the first one Atlanta and wonder what changed since), I wrote a blogpost you might be interested to read at: https://ttx.re/queens-ptg.html As you probably know, at the PTG we encourage workgroups and teams to self-organize their schedule for the day and social networking opportunities for the night, so the event organization is pretty hands-off. We'll still have two happenings during the week that we encourage you to join: * Happy Hour from 5pm to 6pm on Tuesday at the event hotel * Event feedback session during lunch on Thursday Let us know if you have any question, on the #openstack-ptg event channel on IRC or by email at p...@openstack.org. Hoping to see you there! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [infra] Request to delete some unused pages from OpenStack wiki
Chen Ying wrote: > hi Thierry Carrez, > Could you help me to delete this wiki page[1]? This page about > Smaug is not used any longer. Thanks. > > [1] https://wiki.openstack.org/wiki/File:Smaug-available-protectables.svg Done! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions
Doug Hellmann wrote: > If that 2015 version is no longer maintained, then deleting it from > PyPI may be the most effective way to avoid this particular support > issue, even though that is normally not something we recommend. Yeah, in that specific case I think that's the simplest route. It's not really destroying it, it just prevents PyPI from erroneously distributing it, without having to add a PEP440-Epoch to an OpenStack deliverable and discovering all the bugs that it would trigger. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [release] Pike release day - 1
Hi everyone, Pike will be formally released tomorrow before 1500utc, with the last release candidates being promoted to final (for cycle-with-milestones deliverables) and the release page being finalized. A change proposing those promotions is up for review at: https://review.openstack.org/#/c/498263/ PTLs for cycle-with-milestones projects are encouraged to add their +1 to that review, in order to formally record their acceptance in the change metadata. Unless some major new show-stopper appears today, the current Pike intermediary releases and release candidates will be included in the "Pike release" tomorrow. Cheers! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [infra] Request to delete some unused pages from OpenStack wiki
Chen Ying wrote: > The name of the project data protection as a service has been > changed to Karbor for a long time. > The name smuag is no longer needed. So some pages about smaug could be > deleted from OpenStack wiki. > But I don't have permissions. Hope that these pages[1] could be deleted > by anyone who has the > administrator permissions to the wiki. Thanks. Done! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc] Technical Committee Status update, August 18th
Flavio Percoco wrote: > On 18/08/17 11:17 +0200, Thierry Carrez wrote: >> == Need for a TC meeting next Tuesday == >> >> I'll be off next week (therefore skipping this update next Friday). I >> don't think we have anything thoroughly blocked at this point requiring >> a meeting. However if something comes up and requires a meeting next >> week while I'm off, please feel free to self-organize :) > > I'd happy to send the Friday update email until you're back. Awesome! Feel free to update the wiki page in parallel: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
[openstack-dev] [ptg] Room schedule posted for Denver PTG
Hi everyone, The list of available rooms for the Project Teams Gathering in Denver is now finalized, with thematic inter-project rooms on Monday/Tuesday and team-specific meetings on Wednesday/Thursday/Friday. You can find the list (and explanation of what will be covered in each) on the event website at: https://www.openstack.org/ptg#tab_schedule Each of those rooms will self-organize what's being discussed, and expose what's currently being discussed (and what's coming up next) to a common schedule page (driven by the ptgbot on the #openstack-ptg channel). Most room leads have started an etherpad to gather input. You can find them all and add your own topics to discuss at: https://wiki.openstack.org/wiki/PTG/Queens/Etherpads At this point it is still possible to register to join the event at https://www.openstack.org/ptg . The discounted rooms block at the event hotel is now sold out, but Erin outlined options in hotels close to the event venue that you can consider: http://lists.openstack.org/pipermail/openstack-dev/2017-August/121192.html I hope to see you there ! -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, August 18th
Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Resolution to "Describe what upstream support means" [1][2] * Add stable:follows-policy tag for Kolla and oslo.messaging * Pike goals updates: zun * Queens goals updates: murano * New repositories: monasca-events-api, watcher-tempest-plugin [1] https://review.openstack.org/#/c/440601/ [2] https://review.openstack.org/#/c/486964/ John Garbutt's resolution on clarifying what "upstream support" means was finally approved this week. You can read it at: https://governance.openstack.org/tc/resolutions/20170620-volunteer-support.html == PTG prep == We'll have a TC / StewardshipWG room on Monday-Tuesday at the PTG. You can chime in on topics we should cover there on the planning etherpad: https://etherpad.openstack.org/p/queens-PTG-TC-SWG == Election results == We'll have to update the projects.yaml file to reflect the newly-elected PTLs, and are expecting a proposed change from the election officials. For leaderless teams, the TC is proposing to appoint Kota TSUYUZAKI as Storlets PTL for Queens: https://review.openstack.org/#/c/493846/ Packaging-Deb being in the middle of a transition to Debian project infrastructure, we won't be appointing a PTL for Queens, where that team will be retired. == New project teams == As we open Queens cycle development, it's time to reconsider our current backlog of project additions: * Stackube: https://review.openstack.org/462460 The project was set up on OpenStack infrastructure, so it's time to review the proposal again. * Glare: https://review.openstack.org/479285 * Blazar: https://review.openstack.org/482860 * Gluon: https://review.openstack.org/463069 Also ready for review, those teams will be at the PTG and available to spend some time in the TC room on Monday-Tuesday == Open discussions == Monty submitted a new proposal to be explicit about supported database versions. Please review at: https://review.openstack.org/493932 It looks more and more like John's resolution on how decisions should be globally inclusive should be morphed into project-team-guide material. Please review it if you haven't yet, and bring your input before we work on project team guide editions: https://review.openstack.org/#/c/460946/ == Voting in progress == Emmet's rewording of the leaderless project resolution reached majority yesterday and will be approved early next week unless new objections are brought: https://review.openstack.org/#/c/492578/ Flavio's resolutions on dropping Technical Committee meetings[3] and allowing teams to use their channel for meetings[4] are both ready for your voting consideration: [3] https://review.openstack.org/459848 [4] https://review.openstack.org/485117 == Need for a TC meeting next Tuesday == I'll be off next week (therefore skipping this update next Friday). I don't think we have anything thoroughly blocked at this point requiring a meeting. However if something comes up and requires a meeting next week while I'm off, please feel free to self-organize :) Cheers, -- Thierry Carrez (ttx) __ 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
[openstack-dev] [release] Release countdown for week R-1, August 18-25
Welcome to our regular release countdown email! Development Focus - We are entering the last week before release week. Focus should be on producing the last Pike release candidates and intermediary releases, including updated translations and requirements updates. If your team attends the PTG in Denver, you should also be actively preparing the topics for discussion at the event. Actions -- For *cycle-with-intermediary* deliverables, the Pike release will be the last-released version. If you need to release a newer version, you need to do it before August 24. After that date we can't guarantee inclusion in the Pike release, and will fall back to the last-released version. The following deliverables still did not have /any/ release during the Pike cycle and urgently need to make one (and ask for the stable/pike branch to be cut from it). If we don't have anything by the deadline, the release team will have to either force a release, or remove the deliverable from Pike: - ceilometer, panko - magnum, magnum-ui - senlin-dashboard - tacker As a reminder, asking for a release and corresponding stable/pike branch is done by modifying the deliverable Pike release file in the openstack/releases repository and adding: ... - projects: - hash: YOURHASH repo: openstack/YOURPROJECT version: YOUR.NEW.VERSION branches: - location: YOUR.NEW.VERSION name: stable/pike The following deliverables do have an intermediary release in Pike but still haven't asked for a stable/pike branch to be cut. If we don't have a stable/pike branch by the deadline, the release team will branch from the last-available intermediary release: - aodh - instack-undercloud - kuryr-kubernetes - manila-ui - neutron-fwaas-dashboard - swift - tacker-horizon As a reminder, asking for the stable/pike branch to be cut from an already-released Pike version is done by modifying the deliverable Pike release file in the openstack/releases repository and adding: ... branches: - location: YOUR.LAST.PIKEVERSION name: stable/pike For *cycle-with-milestones* deliverables, early next week you should make sure to merge the latest translations patches[1] and latest requirements patches[2], and ask for a last release candidate before the Pike release. As a reminder, asking for a new RC is done by modifying the deliverable Pike release file in the openstack/releases repository and adding: ... - projects: - hash: YOURHASH repo: openstack/YOURPROJECT version: YOURVERSION.0.0.0rc2 [1] https://review.openstack.org/#/q/status:open+branch:stable/pike+topic:zanata/translations [2] https://review.openstack.org/#/q/status:open+branch:stable/pike+topic:openstack/requirements Upcoming Deadlines & Dates -- Deadline for last release candidates / intermediary releases: August 24 Final Pike release: August 30 Queens PTG in Denver: Sept 11-15 As usual come find us on #openstack-release IRC channel if you have any questions or concerns. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [oslo][oslo.config][ansible][tripleo][kolla][ptg] Pluggable drivers and protect plaintext secrets
Raildo Mascena de Sousa Filho wrote: > Hi all, > > Should we reserve a room in the extra session ethercalc [0 > <%20https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms%20>] or > we already have a time slot scheduled for that discussion? > > [0] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms It feels like this discussion could be scheduled in the Oslo room as well. I guess it depends whether you need extra room :) -- Thierry Carrez (ttx) __ 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
[openstack-dev] [ptg] Reservable extra discussion rooms
Hi everyone, The PTG is only in 4 weeks ! It's still time to join the crowd that will be discussing and organizing the Queens development cycle in Denver. Like for Atlanta, for discussions that don't fit in any particular room, we have extra reservable discussion rooms available. Reservation is done through an ethercalc on a first-come first-serve basis (with priority given to official project teams) at: https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms For easier access (especially from mobile devices), the sessions scheduled on the current day will also be published to a static, mobile-friendly page that exposes the topics being currently discussed at the PTG (driven by the ptgbot[1]). [1] http://lists.openstack.org/pipermail/openstack-dev/2017-May/116974.html See you there ! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all][elections] Project Team Lead Election Conclusion and Results
Kendall Nelson wrote: > Hello Everyone! > > Thank you to the electorate, to all those who voted and to all > candidates who put their name forward for Project Team Lead (PTL) in > this election. A healthy, open process breeds trust in our decision > making capability thank you to all those who make this process possible. > Now for the results of the PTL election process, please join me in > extending congratulations to the following PTLs: > [...] Congratulations to all the elected PTLs, new names and returning ones! The PTLs are at the same time a steward for their team, facilitating the work of their teammates, an ambassador for the project, communicating the work being done to the outside world, and a default contact point for anyone having questions about a given team. That can be daunting, especially for larger teams. Don't hesitate to delegate as much of those tasks as you can! Thank you again for your help. Let's make Queens a great cycle! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [release] [telemetry] Ceilometer stable/pike branch outlook
Tony Breeds wrote:
> On Wed, Aug 16, 2017 at 02:37:50PM -0400, William M Edmonds wrote:
>>
>> Julien Danjou wrote on 08/16/2017 02:13:10 PM:
>>> AFAIU it's impossible to cut a branch for our projects and release a rc1
>>> because of the release model we use. The release team does not allow us
>>> to do that. We need to release directly a stable version and cut a
>>> branch.
>>>
>>> I guess we'll do that in a couple of week, at release time.
>>
>> That doesn't fit my understanding of cycle-with-intermediary, which is the
>> the ceilometer release model per [0]. As I read the release model
>> definitions [1], cycle-with-intermediary means that you can have
>> intermediate releases *as well*, but you still have to have a cycle-ending
>> release in line with the projects using the cycle-with-milestones model.
>>
>> Can someone on the release team clarify this for us?
>
> That's correct the bit you're missing is cycle-with-intermediary doesn't
> have pre-releases (b{1,2,3},rc{1,2}) so when the ceilometer team feels
> they have the code in shape for a release they'll tag that release and
> cut a stable/pike branch at the tag point.
Exactly. As explained a couple weeks ago in the release countdown email[1]:
> Deliverables following the cycle-with-intermediary model should also
> create their Pike release branch next week. That means potentially
> making a last Pike release, and in all cases posting the stable/pike
> branch creation request:
>
> ...
> branches:
> - location: YOUR.PIKE.VERSION
> name: stable/pike
[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120574.html
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
__
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
Re: [openstack-dev] [keystone] rc2 updates
Lance Bragstad wrote: > We rolled out rc1 last night [0], but missed a couple important > documentation patches and release notes [1]. I'll propose rc2 as soon as > those merge. Note that we'll have to refresh the RC with translations updates closer to the release anyway (start of R-1 week), so if it's just doc/releasenotes updates, I'd advise you to wait a bit before cutting RC2. Regards, -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
[openstack-dev] [tc] Technical Committee Status update, August 11th
Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Pike goals updates: barbican * Removed repositories: installguide-cookiecutter * New repositories: watcher-tempest-plugin, charm-gnocchi, charm-interface-gnocchi, charm-interface-ceph-client Not much TC activity again this week as everyone is focused on producing Pike release candidates. == Leaderless project teams == We have[1] two teams (3.4% of the total of teams) where nobody stepped up to take the Project Team Lead position for the Queens cycle: Storlets and Packaging-Deb. Following process[2], the Technical Committee will look for and directly appoint a volunteer (or move the team off the official OpenStack project team list if it has no further activity). [1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120915.html [2] https://governance.openstack.org/tc/resolutions/20141128-elections-process-for-leaderless-programs.html In the case of Packaging-Deb, a transition is actually under way[3] to bring it back after Pike to Debian project infrastructure, closer to where Debian maintainers live and usually collaborate, so it's unlikely that the Technical Committee will appoint anyone for Queens. [3] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120581.html For Storlets, the project has been a lot less active lately. I've been reaching out to the two main recent contributors to get a more accurate picture of their plans, so that we can take a decision there. == Open discussions == Flavio just refreshed his resolution about allowing teams to host meetings in their own IRC channels, please see it at: https://review.openstack.org/485117 From the latest reviews, it looks like John's resolution on how decisions should be globally inclusive could use a new patchset (or be morphed into project-team-guide material). Please review it if you haven't yet: https://review.openstack.org/#/c/460946/ Trove's status:maintenance-mode addition is WIP until Queens opens, which should happen very soon now. One question is whether Trove is now past the low point, and setting the tag would convey the wrong message for a recovering project. Please join the discussion if you have an opinion: https://review.openstack.org/#/c/488947/ == Voting in progress == John's description of "what upstream support is" reached majority votes a couple of days ago. It will be approved early on Tuesday unless new objections are raised and votes are changed: https://review.openstack.org/440601 Emmet's rewording of the leaderless project resolution seems to be non-contentious, missing a few votes to pass: https://review.openstack.org/#/c/492578/ == TC member actions for the coming week(s) == All TC members should have a close look on Storlets team status to make up their mind on what to do with it in Queens. Flavio still needs to incorporate feedback in the "Drop TC meetings" proposal and produce a new patchset, or abandon it since we pretty much already implemented the described change. == Need for a TC meeting next Tuesday == It feels like things are progressing slowly, with office hours and general #openstack-tc discussions to nudge them forward. Therefore I don't think we need a synchronous TC meeting next week. Let me know if you'd still like to have one and the topic you would like to see discussed. Cheers! -- Thierry Carrez (ttx) __ 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
[openstack-dev] [release] Release countdown for week R-2, August 11-18
Welcome to our regular release countdown email! Development Focus - As stable/pike branches are now (mostly) cut, focus should be on checking current Pike release candidates for release-critical issues, fix those in master, backport the fix to stable/pike and issue new release candidates before the publication deadline on R-1 (August 24). If your team attends the PTG in Denver, you should also prepare the topics for discussion at the event. General Information --- Probably due to a busy gate, a number of cycle-with-milestones deliverables are still missing their RC1 and stable/pike branch, preventing the thawing of the requirements repository: designate (+ designate-dashboard), freezer-web-ui, heat, manila searchlight (+ searchlight-ui), trove (+ trove-dashboard) In addition to that list, mistral and nova have proposed RC1 tags that just need to be un-WIPped and processed. Please see last week release countdown email[1] and from the requirements team[2] for instructions, if you missed them. [1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120574.html [2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120720.html Note that stable/pike are under hard StringFreeze, in order to let the I18N team do the translation work in good conditions. No change in translatable strings is allowed at this point. Upcoming Deadlines & Dates -- Deadline for last release candidates / intermediary releases: August 24 Final Pike release: August 30 Queens PTG in Denver: Sept 11-15 As usual come find us on #openstack-release IRC channel if you have any questions or concerns. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
joehuang wrote: > Tricircle plans to cut stable/pike branch on August 22nd, it has dependency > on Neutron stable/pike creation. That sounds a bit late to create your release branch. It doesn't give you a lot of time to react to critical issues discovered in that release, as August 24 is the final date to submit new releases for inclusion before Pike is formally declared released. My advice would be to do a X.Y.0 release as soon as you can freeze features (neutron should have their branch this week), and have some time to produce a X.Y.1 bugfix release if you detect critical issues in testing. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [neutron][infra] Functional job failure rate at 100%
Oh, that's good for us. Should still be fixed, if only so that we can test properly :) Kevin Benton wrote: > This is just the code simulating the conntrack entries that would be > created by real traffic in a production system, right? > > On Wed, Aug 9, 2017 at 11:46 AM, Jakub Libosvar <mailto:jlibo...@redhat.com>> wrote: > > On 09/08/2017 18:23, Jeremy Stanley wrote: > > On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote: > > [...] > >> Is it possible to switch used image for jenkins machines to use > >> back the older version? Any other ideas how to deal with the > >> kernel bug? > > > > Making our images use non-current kernel packages isn't trivial, but > > as Thierry points out in his reply this is not just a problem for > > our CI system. Basically Ubuntu has broken OpenStack (and probably a > > variety of other uses of conntrack) for a lot of people following > > kernel updates in 16.04 LTS so the fix needs to happen there > > regardless. Right now, basically, Ubuntu Xenial is not a good > > platform to be running OpenStack on until they get the kernel > > regression addressed. > > True. Fortunately, the impact is not that catastrophic for Neutron as it > might seem on the first look. Not sure about the other projects, though. > Neutron doesn't create conntrack entries in production code - only in > testing. That said, agents should work just fine even with the > kernel bug. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [neutron][infra] Functional job failure rate at 100%
Thanks for this nice detective work, Jakub and Daniel ! This disabled test job was making me nervous wrt. Pike release. Now I suspect that this kernel regression is affecting Ubuntu Xenial users for previous releases of OpenStack, too, so I hope this will get fixed in Ubuntu soon enough. Daniel Alvarez Sanchez wrote: > Some more info added to Jakub's excellent report :) > > > New kernel Ubuntu-4.4.0-89.112HEADUbuntu-4.4.0-89.112master was > tagged 9 days ago (07/31/2017) [0]. > > From a quick look, the only commit around this function is [1]. > > [0] > http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=64de31ed97a03ec1b86fd4f76e445506dce55b02 > [1] > http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=2ad4caea651e1cc0fc86111ece9f9d74de825b78 > > On Wed, Aug 9, 2017 at 3:29 PM, Jakub Libosvar <mailto:jlibo...@redhat.com>> wrote: > > Daniel Alvarez and I spent some time looking at it and the culprit was > finally found. > > tl;dr > > We updated a kernel on machines to one containing bug when creating > conntrack entries which makes functional tests stuck. More info at [4]. > > For now, I sent a patch [5] to disable for now jobs that create > conntrack entries manually, it needs update of commit message. Once it > merges, we an enable back functional job to voting to avoid regressions. > > Is it possible to switch used image for jenkins machines to use back the > older version? Any other ideas how to deal with the kernel bug? > > Thanks > Jakub > > [5] https://review.openstack.org/#/c/492068/1 > <https://review.openstack.org/#/c/492068/1> > > On 07/08/2017 11:52, Jakub Libosvar wrote: > > Hi all, > > > > as per grafana [1] the functional job is broken. Looking at > logstash [2] > > it started happening consistently since 2017-08-03 16:27. I didn't > find > > any particular patch in Neutron that could cause it. > > > > The culprit is that ovsdb starts misbehaving [3] and then we retry > calls > > indefinitely. We still use 2.5.2 openvswitch as we had before. I > opened > > a bug [4] and started investigation, I'll update my findings there. > > > > I think at this point there is no reason to run "recheck" on your > patches. > > > > Thanks, > > Jakub > > > > [1] > > > > http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=7&fullscreen > > <http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=7&fullscreen> > > [2] http://bit.ly/2vdKMwy > > [3] > > > > http://logs.openstack.org/14/488914/8/check/gate-neutron-dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz > > <http://logs.openstack.org/14/488914/8/check/gate-neutron-dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz> > > [4] https://bugs.launchpad.net/neutron/+bug/1709032 > <https://bugs.launchpad.net/neutron/+bug/1709032> > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > > > __ > 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 (ttx) __ 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
Re: [openstack-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements
Bhor, Dinesh wrote: > I would like to ask for the FFE for adding "*python-masakariclient*" in > global-requirements. > > Earlier, we were not having "check-requirements" job for masakari-* > projects. At that time, we use to manually add "*python-masakariclient*" > as a requirement in *masakari-monitors* project [1]. > > Now we have added "*check-requirements*" job for masakari-* projects, > but we missed to add "python-masakariclient" in global-requirements and > now the bigger issue is it is not possible > > to *manually update* the "python-masakariclient" requirement in > masakari-monitors project as the "*gate-masakari-monitors-requirements*" > requirements job keeps failing on the patch [1]. > > To resolve this problem permanently, we need to add > "python-masakariclient" library requirement in global-requirements. > > I have submitted a patch [2] for adding the python-masakariclient in > global-requirements. > > Please consider my request and grant FFE to solve this problem. > > [1] https://review.openstack.org/#/c/457491/ > [2] https://review.openstack.org/#/c/491692/ It feels like this could wait until we create a stable/pike branch for the requirements (which will happen as soon as we have RC1 for all cycle-with-milestones projects, in theory at the end of this week, in practice probably early next week). -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [oslo][oslo.config][ansible][tripleo][kolla][ptg] Pluggable drivers and protect plaintext secrets
Emilien Macchi wrote: > On Mon, Aug 7, 2017 at 9:15 AM, Doug Hellmann wrote: >> Kendall & Thierry, what do we need to do to reserve that room if we >> can't find space in another team room? > > Worst case, we can use a slot from TripleO - this topic is also > critical to us and I think we can make our schedule to have one free > room during the 2 and a half days that we have. > Just let me know. It could also be scheduled in one of the extra reservable rooms we have on Thursday/Friday. The ethercalc for that should be up next week. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [mistral][heat][tripleo][trove][murano][solum][tacker] Releasing python-mistralclient 3.1.2
Renat Akhmerov wrote: > [...] > So long story short, this change will affect your project only if you > use “mistral action-execution-list” CLI command because now this command > will be returning by default only 100 entries (to return all > “--limit=-1” needs to be passed). A number of projects depend on python-mistralclient: openstack/python-tripleoclient[cycle-trailing] openstack/python-troveclient [cycle-with-intermediary] openstack/heat[cycle-with-milestones] openstack/mistral [cycle-with-milestones] openstack/murano [cycle-with-milestones] openstack/solum [cycle-with-intermediary] openstack/tacker [cycle-with-intermediary] openstack/instack-undercloud [cycle-with-intermediary] openstack/mistral-dashboard [None] openstack/openstackclient [None] openstack/python-openstackclient [cycle-with-intermediary] openstack/tripleo-common [cycle-trailing] However, I suspect none of those go through the CLI, so they likely won't be affected by the proposed change and could still depend on >=3.1.1 (therefore avoiding re-releases). Could you have a quick look at those and confirm that ? > We at Nokia need this fix released in Pike because we need to trigger > updates of RDO packages used in our system. Since this change affects behavior, it's better to do it before Pike release than after Pike release as a stable point update. So if my hunch on CLI usage above is right, then I would rather grant the library release freeze exception now. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [docs] Updating the docs team mission statement
Petr Kovar wrote: > Hi all, > > With the core docs suite moving from openstack-manuals to individual > project repos as per > http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html, > it's also time to update the docs team mission statement from > https://governance.openstack.org/tc/reference/projects/documentation.html. > > What are everybody's thoughts on what should the new mission statement > say now that most OpenStack docs maintenance is in the hands of project > teams? > > One idea is for the docs team to act as a focused group of editors and > maintain a common set of guidelines, recommended practices (style > guidelines come to mind, for instance), and requirements (such as a common > docs and publishing structure shared across projects). I would say something like: The docs team provides guidance, assistance, tooling, and style guides enabling OpenStack project teams to produce consistent, accurate, and high-quality documentation. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, August 4th
Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Pike goals updates: nova, cinder * New repositories: publiccloud-wg, oswin-tempest-plugin Not much TC activity this week as we past Pike Feature Freeze and everyone is focused on producing Pike release candidates. == Stuck tags == We have a number of non-straightforward tag additions in the queue, which need a bit more input before they can proceed: Kolla's stable:follows-policy application [1] has been proposed July 2016 but was delayed for various reasons. Currently stuck near the goal line waiting on some last-minute commitment. Would be great to merge it before Pike release so that it can be included in the project navigator. Nova and Ironic's assert:supports-api-interoperability addition[2] is missing their respective PTL support for them. It also triggered an interesting side discussion on the value of tags in general and this tag in particular. This one will likely be abandoned unless it gets the PTL support on them. Trove's status:maintenance-mode addition[3] is WIP until Queens opens. One question is whether Trove is now past the low point, and setting the tag would convey the wrong message for a recovering project. Please join the discussion if you have an opinion. [1] https://review.openstack.org/346455 [2] https://review.openstack.org/#/c/482759/1 [3] https://review.openstack.org/#/c/488947/ == Open discussions == Flavio's resolution about allowing teams to host meetings in their own IRC channels is still in the early days of discussion, and is likely to need a few iterations to iron out. Please join the first round of reviews: https://review.openstack.org/485117 Discussion on John's resolution on how decisions should be globally inclusive is entering the final stages. Please review it if you haven't yet: https://review.openstack.org/#/c/460946/ == Voting in progress == The description of what upstream support is still missing a few votes to pass. Please review it now: https://review.openstack.org/440601 == TC member actions for the coming week(s) == Flavio still needs to incorporate feedback in the "Drop TC meetings" proposal and produce a new patchset, or abandon it since we pretty much already implemented the described change. == Need for a TC meeting next Tuesday == Currently-proposed changes are lacking reviews more than they are stuck, so I don't think we need a synchronous TC meeting next week. Let me know if you'd like to have one and the topic you would like to see discussed. Cheers! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project
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 some questions in #openstack-sdks with no responses. > I see that there are some maintenance patches getting merged and a pypi > release was made 6/14/17 (though not through releases project). I'm not > seeing any mailing list traffic and the IRC meetings seem to have ended in > 2016. > > With all the recent contributor changes, I want to make sure the project > isn't adrift in the sea of OpenStack before we continue to spend development > time implementing the SDK for Octavia. We were also planning to use it as > the backing for our dashboard project. > > Since it's not in the governance projects list I couldn't determine who the > PTL to ping would be, so I decided to ping the dev mailing list. > > My questions: > 1. Is this project abandoned? > 2. Is there a plan to make it an official project? > 3. Should we continue to develop for it? Thanks for raising this. Beyond its limited activity, another issue is that it's not an official project while its name make it a "default choice" for a lot of users (hard to blame them for thinking that http://git.openstack.org/cgit/openstack/python-openstacksdk is not the official Python SDK for OpenStack, but I digress). So I agree that the situation should be clarified. I know that Monty has pretty strong feelings about this too, so I'll wait for him to comment. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [release] Release countdown for week R-3, Aug 4 - Aug 11
Welcome to our regular release countdown email! Development Focus - Focus should be on the last Pike release-critical bugs, in order to produce the first Pike release candidates sometimes during the week. General Information --- We are at the point in the cycle where release branches should be cut. The stable/pike branch will track the Pike release, while the master branch will switch to Queens development (and no longer be feature-frozen). Future release candidates (or last-minute point releases fixing critical issues) will be cut from those release branches. Fixes first need to land in the master branch (so that we don't inadvertantly create a regression in Queens), then be backported to stable/pike before the new release candidate is tagged. Actions --- Deliverables following the cycle-with-milestones model should post a RC1 openstack/releases request during the week (X.0.0.0rc1), together with a stable/pike branch request. It should include something like this: ... - projects: - hash: YOURHASH repo: openstack/YOURPROJECT version: YOURVERSION.0.0.0rc1 branches: - location: YOURVERSION.0.0.0rc1 name: stable/pike Deliverables following the cycle-with-intermediary model should also create their Pike release branch next week. That means potentially making a last Pike release, and in all cases posting the stable/pike branch creation request: ... branches: - location: YOUR.PIKE.VERSION name: stable/pike Upcoming Deadlines & Dates -- RC1 target deadline (and HardStringFreeze): August 10 Final Pike release: August 30 Queens PTG in Denver: Sept 11-15 As usual come find us on #openstack-release IRC channel if you have any questions or concerns. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [all] Only 40 days to PTG !
Hi everyone, Time flies, and we are just 40 days from the Project Teams Gathering in Denver. Time for a few reminders! 1/ Registration If you haven't registered yet, you should do so[1] ASAP. Beyond securing your slot to the event, it helps us planning for rooms and lunches based on your days of attendance. [1] https://queensptg.eventbrite.com/ 2/ Travel support program If you'd like to come join your project team in Denver but need financial help, our Travel Support Program[2] is still open. However the deadline for applications is *this Sunday, August 6*, so don't forget to apply in time ! [2] https://openstackfoundation.formstack.com/forms/travelsupportptg_denver 3/ Visa If you need a visa, it's getting pretty late to go through the whole process in time for the event. Let us know ASAP if you need an invitation letter[3] ! [3] https://openstackfoundation.formstack.com/forms/visa_form_denver_ptg 4/ Event layout We are still finalizing the list of teams and rooms that will meet at the event[4]. As previously announced, this time the week is split in the following way: - Monday/Tuesday: inter-team discussions on specific themes: workgroup discussions, help desks from various support teams, discussions for teams relying on liaisons like Oslo / Horizon / Docs, release goals hacking rooms... - Wednesday-Thursday-Friday: discussions within each project team to coordinate the Queens work, solve pressing issues and start getting things done [4] https://docs.google.com/spreadsheets/u/1/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312&single=true Let me know if you have any question. You can also ask questions on #openstack-ptg, or contact the events team at p...@openstack.org. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [release][requirements] FFE release for reno 2.5.0
Doug Hellmann wrote: > We have a few projects that have modified stable branch release > notes by editing the files on master, which makes those notes appear > as part of the current release. Reno has a new option to address > that problem by ignoring some note files, and I would like to release > that version to allow project teams to fix up their release notes > for pike. I really thought I had already released that update, so > I'm sorry for the late request. > > Reno is only used during release notes builds, but it does appear > in the global requirements list and constraints list. I think the > risk is minimal. > > https://review.openstack.org/489998 Sounds like something we should fix before release rather than after, so +2 from me. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [SPAM] [all][docs] recruiting for help with documentation tools
Doug Hellmann wrote: > [...] > The areas we need help are maintaining the doc build jobs, the > sphinx extensions in oslo.config and oslo.policy, the Sphinx theme, > and the template build tool in the openstack-manuals git repo. These > are all minimally complete, but there is definitely feature work > and bug fixing to do. I can guarantee that, if you sign up to help, > you will have a chance to land changes that will be visible for all > OpenStack users. At the start of Queens, I will be doing some > one-on-one training with volunteers to ensure they understand the > system we have in place now and help them start on some of the > remaining feature work. > [...] Feels like the doc owners/liaisons that we are looking for in the Top 5 help wanted list[1] would be in a good position to help with that. Should we extend the description of the need so that it's clearer that help with maintaining the doc toolchain is also a top wanted thing ? [1] https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [SPAM] Re: [security][barbican] PTG room sharing
Luke Hinds wrote: > Thanks Dave, I will let Kendall know that we can free up the room from > Mon / Tuesday, and instead have the sec proj join barbican on Wed / Thur. Note that we have extra room on Monday/Tuesday, so it would be OK to keep the room to have cross-project "security discussions", even if you'll have your team internal-facing meetings on Wed-Fri... For example we could use the time to advance the discussion around making Castellan/barbican a base service that every other project can depend on being present. Or any other cross-project discussion with a security focus. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc][kolla] Distribute Ansible module with Kolla
Steven Dake wrote: > Doung, > > The TC cannot provide legal advice as they are not attorneys (forgive me > if there are TC members that also have legal credentials coupled with a > legal degree). I'd suggest contacting your specific companies legal > counsel. If that doesn't yield results, you might try the legal list. > > The dev mailer is no place for this discussion. Although I'm not a lawyer, I replied on the legal-discuss thread asking for more information, and pointing to: https://governance.openstack.org/tc/reference/licensing.html Let's follow-up there. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [release]need help for python-tricircleclient
joehuang wrote: > The patch [1] is to add a tag for python-tricircleclient after new > features were added to it since last release. But unfortunately, a > branch called "stable/pike" was there in Apr., and lead to the patch can > not pass the gate test. This release request missed the deadline for client libraries releases (if only by a few hours), so we already created the stable/pike branch from the last available Pike release (0.1.1 from April 2017). Given (1) that the deadline was not missed by much, (2) that the last available release was quite old, and (3) that no other project depends on python-tricircleclient, damage would be limited in cutting 0.2.0 now and recreating stable/pike from it. We'll coordinate with infra to make it happen. Next time, please don't miss the deadline and create additional work for the release team ! -- Thierry Carrez (ttx) __ 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
[openstack-dev] [release] Release countdown for week R-4, July 28 - Aug 4
Welcome to our regular release countdown email! Development Focus - Focus should be on fixing release-critical bugs in order to produce the first release candidates (for deliverables following the with-milestones model) or final Pike releases (for deliverables following the with-intermediary model), with the R-3 week as a target date (August 10). General Information --- For deliverables following the cycle-with-milestones model, we are now past Feature Freeze. The focus should be on determining and fixing release-critical bugs. At this stage only bugfixes should be approved for merging in the master branches: feature work should only be considered if explicitly granted a Feature Freeze exception by the team PTL (after a public discussion on the mailing-list). StringFreeze is now in effect, in order to let the I18N team do the translation work in good conditions. The StringFreeze is currently soft (allowing exceptions as long as they are discussed on the mailing-list and deemed worth the effort). It will become a hard StringFreeze on August 10. The requirements repository is also frozen, until all cycle-with-milestones deliverables have produced a RC1 and have their stable/pike branches. Note that deliverables that are not tagged for release by the appropriate deadline will be reviewed to see if they are still active enough to stay on the official project list. Actions --- A few cycle-with-milestones deliverables still haven't requested their Pike-3 tag (X.0.0.0b3): heat networking-bagpipe networking-bgpvpn networking-midonet networking-odl networking-ovn networking-sfc neutron-dynamic-routing neutron-fwaas neutron and sahara. If nothing is proposed by the end of the day, a tag will be forced at the current master HEAD in order to mark the Feature Freeze. stable/pike branches should be created soon for all non-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. For cycle-with-intermediary deliverables, release liaisons should consider releasing their latest version, and creating stable/pike branches from it ASAP. For cycle-with-milestones deliverables, release liaisons should wait until R-3 week to create RC1 (to avoid having an RC2 created quickly after). Review release notes for any missing information, and start preparing "prelude" release notes as summaries of the content of the release so that those are merged before the first release candidate. For release-independent deliverables, release liaisons should check that their deliverable file includes all the existing releases, so that they can be properly accounted for in the releases.openstack.org website; Finally, if you haven't done so already, remember to file Pike goal completion information, as explained in: https://governance.openstack.org/tc/goals/index.html#completing-goals Upcoming Deadlines & Dates -- RC1 target deadline (and HardStringFreeze): August 10 Final Pike release: August 30 Queens PTG in Denver: Sept 11-15 As usual come find us on #openstack-release IRC channel if you have any questions or concerns. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases
Andreas Jaeger wrote: > On 2017-07-27 21:40, Doug Hellmann wrote: >> [...] >> Please encourage everyone there to explore options that require the >> least amount of effort. An ideal solution is one we can implement >> without heroic efforts or having to recruit an army of contributors. > > I agree with the points made in general and want to stress we need > something that reduces our efforts. Yes, agree on the general idea of keeping docs around "forever". > Two more ideas: > > 1) What about enhancing the openstackdocstheme to automatically add a > watermark if we publish a stable branch document? > Like on https://docs.openstack.org/mitaka/config-reference/ - which also > includes a warning that the branch is EOL. What about adding at *start* > of a branch a message to the index page like "This is the document for > the SERIES release. Please see https://releases.openstack.org/ whether > the SERIES release is still supported by the OpenStack community." That would be a great way of ensuring that old content is not mistaken for currently-maintained content, encouraging old users to migrate to newer / better-supported versions. > 2) The openstackdocstheme has the report a bug link feature. We can > disable this. If we EOL docs (so, push a change before we eol them), we > could remove the setting so that "report a bug" does not work. Cheers, -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Technical Committee Status update, July 28th
Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Declare plainly the current state of PostgreSQL in OpenStack [1] * Clean up remaining 'big tent' mention in Licensing requirements [2] * Queens goals updates: octavia * New repositories: charm-deployment-guide * Repositories moved to legacy: api-site, faafo * Removed repositories: deb-mistral-dashboard [1] https://review.openstack.org/#/c/427880/ [2] https://review.openstack.org/484607 The big item of the week is the final merge, after almost 6 months of discussion, of the resolution declaring plainly the state of PostgreSQL in OpenStack: https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html Additionally, the governance repository was tagged in preparation for the PTL elections, to clearly define the teams and associated repositories that will be considered. == Open discussions == Flavio's resolution about allowing teams to host meetings in their own IRC channels is still in the early days of discussion, and is likely to need a few iterations to iron out: https://review.openstack.org/485117 Discussion on John's resolution on how decisions should be globally inclusive is entering the final stages. Please review it if you haven't yet: https://review.openstack.org/#/c/460946/ == Voting in progress == The description of what upstream support means seems to be ready for voting: https://review.openstack.org/440601 == TC member actions for the coming week(s) == Flavio still needs to incorporate feedback in the "Drop TC meetings" proposal and produce a new patchset, or abandon it since we pretty much already implemented the described change. Thierry needs to reach out to existing WG to propose them to migrate to the new SIG format. == Need for a TC meeting next Tuesday == No initiative is currently stuck, so there is no need for a TC meeting next week. Cheers! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [release] nominating Sean McGinnis for releases-core
Doug Hellmann wrote: > Sean has been increasingly active with the release team this cycle, and > wants to contribute. I think we should go ahead and add him to the > releases-core group. > > Please respond +1/-1. +1! -- Thierry Carrez (ttx) __ 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
[openstack-dev] [relmgt] Non-candidacy for the Queens cycle Release management PTL
Hi everyone, I don't intend to run for Release management PTL for Queens. If you're interested in this role, I encourage you to apply when the nomination period opens (July 31). You might be interested in reviewing [1], which describes the still-not-automated parts of release management for OpenStack. In addition to those team duties, the PTL is expected to run the release team meeting and send the regular release countdown emails. [1] http://git.openstack.org/cgit/openstack/releases/tree/PROCESS.rst I have multiple reasons for not running this cycle. First, as part of my expanded role at the Foundation my travel commitments increased a bit. The Release management PTL role requires regular work: I ended up doing a relatively bad job at PTLing this cycle, by being away during a number of critical weeks. Fortunately, I could count on the presence of the other team members (especially dhellmann and dims) to keep things under control! Second, I believe in expanding the pool of people who can do this job for OpenStack, and in general in regular rotation of the PTL roles to avoid burnout. I'm not going anywhere though, I'll still be part of the team and I intend to continue to take my fair share of the release management duties ! Whoever steps up and gets elected will be able to count on a solid team of seasoned release managers and mentors :) Regards, -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Status update, July 21th
Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Technical Committee 2019 vision [1][2][3][4] * Refreshed extra-ATC list for I18n team [5] * New tags: stable:follows-policy for Congress * Pike goals update: tricircle * Queens goals update: keystone * New repositories: os_tacker [1] https://review.openstack.org/#/c/453262/ [2] https://review.openstack.org/#/c/473620/ [3] https://review.openstack.org/#/c/482152/ [4] https://review.openstack.org/#/c/482686/ [5] https://review.openstack.org/#/c/483452/ The significant item of the week is of course the publication of the 2019 TC vision, which we had been working on since March. The idea here is to describe a desirable point in the future, to help inform our collective decisions. Of course future Technical Committee memberships may differ on what this desirable future looks like, and could come up with new visions to replace this one. You can find the TC 2019 vision at: https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html == Open discussions == Flavio Percoco posted a new resolution about allowing teams to host meetings in their own IRC channels: https://review.openstack.org/485117 Project team additions are currently frozen until the opening of the Queens cycle. A number of teams are in the backlog, please comment on their respective reviews and threads if you have concerns about how well they fit the OpenStack mission or the community principles: Blazar: https://review.openstack.org/#/c/482860/ Glare: https://review.openstack.org/#/c/479285/ Gluon: https://review.openstack.org/463069 Stackube: https://review.openstack.org/462460 Finally, discussion is still in progress on two clarifications from John Garbutt, where we continue to iterate on patchsets: Decisions should be globally inclusive: https://review.openstack.org/#/c/460946/ Describe what upstream support means: https://review.openstack.org/440601 == Voting in progress == The long-standing "Declare plainly the current state of PostgreSQL in OpenStack" resolution now has majority support, and will be approved Monday unless new objections are raised: https://review.openstack.org/#/c/427880/ == TC member actions for the coming week(s) == None that I can think of. == Need for a TC meeting next Tuesday == No initiative is currently stuck, so there is no need for a TC meeting next week. Cheers! -- Thierry Carrez (ttx) __ 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
[openstack-dev] [release] Release countdown for week R-5, July 21 - 28
Welcome to our regular release countdown email!
Development Focus
-
Teams should be wrapping up Pike feature work, in preparation for
Feature Freeze for client libraries and services following the
cycle-with-milestones release model.
General Information
---
Next week is the deadline for releasing client libraries (meaning:
all libraries that are python-${PROJECT}client API client libraries).
stable/pike branches will be cut from the most recent Pike releases. So
if your master branch contains changes that you want to see in the Pike
release branch, you should definitely consider asking for a new client
library release.
python-designateclient, python-searchlightclient and python-swiftclient
haven't made a Pike release yet: if nothing is done by July 27, one
release will be forced (on master HEAD) so that we have something to cut
a stable branch from.
For deliverables following the cycle-with-milestones model, next week is
also when Feature Freeze will hit and the pike-3 milestone will be
tagged. After that date, only bugfixes should be accepted, in
preparation for producing the first release candidate. Feature freeze
exceptions may be exceptionally granted up to RC1 for services, if
required to produce a clean and functional release. For those
deliverables, stable/pike branches will be created when the first
release candidate is tagged on master, and further release candidates
may be produced on the stable/pike branch until the final release date.
During all that period, StringFreeze is in effect, in order to let the
I18N team do the translation work in good conditions. The StringFreeze
is soft (allowing exceptions as long as they are discussed on the
mailing-list and deemed worth the effort). It becomes a hard
StringFreeze on August 10.
See all details at:https://releases.openstack.org/pike/schedule.html
Actions
---
stable/pike branches shall be created Friday for all non-client
libraries. You should expect 3 changes to be proposed for each: a
.gitreview update, a reno update and a tox.ini constraints URL update.
Please review those in priority so that the branch can be functional ASAP.
Upcoming Deadlines & Dates
--
Client libraries final releases: July 27
Pike-3 milestone (and Feature freeze): July 27
RC1 target deadline (and HardStringFreeze): August 10
Final Pike release: August 30
Queens PTG in Denver: Sept 11-15
--
Thierry Carrez (ttx)
__
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
Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects
Erno Kuvaja wrote: > [...] > So this raises a question: If it is integral part of Glare becoming > part of big tent, does it mean that we as OpenStack Community > fundamentally agree on that goal? because in that case I would be way > less supportive. [...] Approving Glare as an official OpenStack project wouldn't bless it as Glance NG, it would just be recognizing that Glare is being developed by members of the OpenStack community, following our open development principles, and that the scope of the project is helping with the OpenStack mission. I think we are mostly comfortable with the first part (the principles match). We are slightly less comfortable with the second part (the scope match). If we determined that Glare is actively hurting OpenStack mission (by adding confusion or gratuitously duplicating effort or introducing interoperability issues) we would likely have to reject it. Mike's answers are reassuring, so I'm looking forward to continuing this discussion on this list and at the Denver PTG, and finally make the call at the start of the Queens cycle. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Status update, July 13th
Hi! With a few hours in advance (blame Bastille Day!) this is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Add Queens goal: policy and docs in code [1][2][3] * Add champions to selected Pike goals [4] * Remove remaining 'big tent' references [5] * New repositories: castellan-ui, tripleo-upgrade, os-service-types, tempest-tripleo-ui [1] https://review.openstack.org/#/c/469954/ [2] https://review.openstack.org/#/c/475882/ [3] https://review.openstack.org/#/c/481654/ [4] https://review.openstack.org/#/c/482869/ [5] https://review.openstack.org/#/c/480500/ So the cross-project goals for the Queens cycle have been defined, you can find them at: https://governance.openstack.org/tc/goals/queens/index.html One difference with the Pike goals is that each goal will have an active champion to project-manage them to completion, providing assistance, reminders and sometimes direct help to the project teams. == Open discussions == We have two new project teams being actively discussed, for potential approval once the Queens cycle is opened: Glare[6][7] and Blazar[8]. Please ask questions or voice your objections at: [6] https://review.openstack.org/#/c/479285/ [7] http://lists.openstack.org/pipermail/openstack-dev/2017-July/119442.html [8] https://review.openstack.org/#/c/482860/ Discussion is still in progress on two clarifications from John Garbutt, where new patchsets have been recently posted: Decisions should be globally inclusive: https://review.openstack.org/#/c/460946/ Describe what upstream support means: https://review.openstack.org/440601 == Voting in progress == The TC vision for 2019 was discussed at a recent TC meeting[9], brilliantly summarized by cdent at [10]. [9] http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-07-11-20.01.html [10] http://lists.openstack.org/pipermail/openstack-dev/2017-July/119569.html It now has majority votes, and is about to be approved early next week, in the form of the following patch chain: https://review.openstack.org/#/c/453262/ https://review.openstack.org/#/c/473620/ https://review.openstack.org/#/c/482152/ https://review.openstack.org/#/c/482686/ This vision is of course produced on a specific date by a specific membership of the TC. Future TC members should definitely revisit it and potentially produce a new vision for another point in the future if they feel like the current vision is no longer productive. The long-standing "Declare plainly the current state of PostgreSQL in OpenStack" resolution is just one formal vote away from being approved: https://review.openstack.org/#/c/427880/ Finally, a number of tag changes are about to be approved: unless there are objections congress should get the stable:follows-policy tag[11], and Nova and Ironic should get the assert:supports-api-interoperability tag[12] [11] https://review.openstack.org/479030 [12] https://review.openstack.org/482759 == TC member actions for the coming week(s) == flaper87 to update "Drop Technical Committee meetings" with a new revision dims to sync with Stackube on progress and report back == Need for a TC meeting next Tuesday == No initiative is currently stuck, so there is no need for a TC meeting next week. Cheers! -- Thierry Carrez (ttx) __ 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
[openstack-dev] [release] Release countdown for week R-6, July 14 - July 21
Welcome to our regular release countdown email!
Development Focus
-
Teams should be wrapping up Pike feature work, prioritizing non-client
libraries first, then everything else (services, client libraries...)
General Information
---
Next week is the deadline for releasing non-client libraries (meaning:
all libraries that are not python-${PROJECT}client API client libraries).
stable/pike branches will be cut from the most recent Pike releases. So
if your master branch contains changes that you want to see in the Pike
release branch, you should definitely consider asking for a new release.
glance-store and instack haven't made a Pike release yet: if nothing is
done by July 20, one release will be forced (on master HEAD) so that we
have something to cut a stable branch from.
For the rest of the cycle-with-milestones deliverables, feature freeze
will hit on July 27. After that date, only bugfixes should be accepted
(feature freeze exceptions may be granted up to RC1 for services).
During all that period, StringFreeze is in effect, in order to let the
I18N team do the translation work in good conditions. The StringFreeze
is soft (allowing exceptions as long as they are discussed on the
mailing-list and deemed worth the effort). It becomes a hard
StringFreeze on August 10.
See all details at:https://releases.openstack.org/pike/schedule.html
Actions
---
All project teams should prioritize updating the organization of their
documentation according to the migration spec [1] to facilitate
linking to it accurately from docs.openstack.org. Please complete
this work before creating your stable/pike branch. Contact
the docs team if you need assistance or have questions.
[1]
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html
Upcoming Deadlines & Dates
--
Non-client libraries final releases: July 20
Client libraries final releases: July 27
Pike-3 milestone (and Feature freeze): July 27
Final Pike release: August 30
Queens PTG in Denver: Sept 11-15
--
Thierry Carrez (ttx)
__
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
Re: [openstack-dev] [Release-job-failures] Release of openstack/monasca-log-api failed
jenk...@openstack.org wrote: > - monasca-log-api-tarball > http://logs.openstack.org/ff/ff2f6a9660b478a2de6fd3ffa33c7dc9d0cd6892/release/monasca-log-api-tarball/cb3c8be/ > : FAILURE in 3m 07s The error is generated while building the tarball: can't copy 'etc/monasca/log-api.conf': doesn't exist or not a regular file The issue is that etc/monasca/log-api.conf is still in the data_files in setup.cfg, but it's been removed by commit d243ed35. https://review.openstack.org/481539 should fix it. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Status update, July 7th
Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Add "Glance Contributors" to top-5 wanted list [1] * Doc link updates: octavia * Goal completion updates: octavia, nova [1] https://review.openstack.org/#/c/474604/ So we now have two items in our "Top 5 help wanted" list: doc owners and glance contributors. Those are duties that the TC deems beneficial to all of OpenStack and necessary to our continued success. You can find the list at: https://governance.openstack.org/tc/reference/top-5-help-wanted.html == Open discussions == Glare was officially proposed as a new official project team. Please ask questions or voice your objections at: https://review.openstack.org/#/c/479285/ The two changes around TC 2019 vision are still up for review. We are ready to take those to the next stage, so if you haven't already, please see those at: https://review.openstack.org/#/c/453262/ https://review.openstack.org/#/c/473620/ Discussion also continues on two clarifications from John Garbutt: Decisions should be globally inclusive: https://review.openstack.org/#/c/460946/ Describe what upstream support means: https://review.openstack.org/440601 Discussion on Queens goals is nearing the end. We seem to have general consensus on the two proposed goals, and champions have volunteered to drive them. If you disagree, please chime in on the thread at: http://lists.openstack.org/pipermail/openstack-dev/2017-June/118808.html == Voting in progress == Vote has started on the patch proposing to remove the last remaining 'big tent' references: https://review.openstack.org/#/c/480500/ == TC member actions for the coming week(s) == flaper87 to update "Drop Technical Committee meetings" with a new revision, when he finishes celebrating his birthday. dims to sync with Stackube on progress and report back == Need for a TC meeting next Tuesday == I propose we have a meeting next week to discuss the next steps in establishing the vision. I feel like we should approve it soon, otherwise we'll get too close to the vision date (Spring 2019)... We also need to wrap up the goals (selecting the two and deferring the others). Who is up for discussing those items at our usual meeting slot time on Tuesday ? Cheers! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all][tc] Wiki
Flavio Percoco wrote: > On 03/07/17 13:58 +0200, Thierry Carrez wrote: >> Flavio Percoco wrote: >>> Sometimes I wonder if we still need to maintain a Wiki. I guess some >>> projects still use it but I wonder if the use they make of the Wiki >>> could be moved >>> somewhere else. >>> >>> For example, in the TC we use it for the Agenda but I think that >>> could be moved >>> to an etherpad. Things that should last forever should be documented >>> somewhere >>> (project repos, governance repo in the TC case) where we can actually >>> monitor >>> what goes in and easily clean up. >> >> This is a complete tangent, but I'll bite :) We had a thorough >> discussion about that last year, summarized at: >> >> http://lists.openstack.org/pipermail/openstack-dev/2016-June/096481.html >> >> TL,DR; was that while most authoritative content should (and has been >> mostly) moved off the wiki, it's still useful as a cheap publication >> platform for teams and workgroups, somewhere between a git repository >> with a docs job and an etherpad. >> >> FWIW the job of migrating authoritative things off the wiki is still >> on-going. As an example, Thingee is spearheading the effort to move the >> "How to Contribute" page and other first pointers to a reference website >> (see recent thread about that). > > I guess the short answer is that we hope one day we won't need it. I > certainly > do. > > What would happen if we make the wiki read-only? Would that break peopl's > workflow? > > Do we know what teams modify the wiki more often and what it is they do > there? The data is publicly available (see recent changes on the wiki). Most ops workgroups heavily rely on the wiki, as well as a significant number of upstream project teams and workgroups. Developers are clearly not the main target. You can dive back into the original analysis etherpad if you're interested: https://etherpad.openstack.org/p/wiki-use-cases Things that are stroked out are things we moved to reference websites since then. -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [all][tc] Wiki (was: How to deal with confusion around "hosted projects")
Flavio Percoco wrote: > Sometimes I wonder if we still need to maintain a Wiki. I guess some > projects still use it but I wonder if the use they make of the Wiki could be > moved > somewhere else. > > For example, in the TC we use it for the Agenda but I think that could be > moved > to an etherpad. Things that should last forever should be documented somewhere > (project repos, governance repo in the TC case) where we can actually monitor > what goes in and easily clean up. This is a complete tangent, but I'll bite :) We had a thorough discussion about that last year, summarized at: http://lists.openstack.org/pipermail/openstack-dev/2016-June/096481.html TL,DR; was that while most authoritative content should (and has been mostly) moved off the wiki, it's still useful as a cheap publication platform for teams and workgroups, somewhere between a git repository with a docs job and an etherpad. FWIW the job of migrating authoritative things off the wiki is still on-going. As an example, Thingee is spearheading the effort to move the "How to Contribute" page and other first pointers to a reference website (see recent thread about that). -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion
Mike Perez wrote: > [...] > What do people think before we bikeshed on the name? Would having a > champion volunteer to each goal to help? It feels like most agree that having champions would help. Do we have any volunteer for the currently-proposed Pike goals ? As a reminder, those are: * Split Tempest plugins into separate repos/projects [1] * Move policy and policy docs into code [2] [1] https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html [2] https://review.openstack.org/#/c/469954/ -- Thierry Carrez (ttx) __ 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
[openstack-dev] [tc] Status update, Jun 30
Hi! This is the weekly update on Technical Committee initiatives. You can find the full list of all open topics at: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee == Recently-approved changes == * Introduce assert:supports-api-interoperability tag [1] * Move Fuel from official to unofficial (hosted) [2] * Team diversity tags update [3] * Do not use confusing "meritocracy" word in the opens [4] * Goal completion updates from: glance * New git repositories: neutron-fwaas-dashboard, freezer-tempest-plugin, ptgbot, puppet-ptgbot, logstash-filters, ironic-python-agent-builder [1] https://review.openstack.org/#/c/418010/ [2] https://review.openstack.org/#/c/475721/ [3] https://review.openstack.org/#/c/475844/ [4] https://review.openstack.org/#/c/473510/ The "assert:supports-api-interoperability" tag can be asserted for deliverables which follow the API interoperability guidelines and that they will not change (or remove) an API in a way that will break existing users of an API. See details at: https://governance.openstack.org/tc/reference/tags/assert_supports-api-interoperability.html == Open discussions == The two changes around TC vision are still up for review. Please see those at: * Initial draft [5] * Subsequent draft integrating feedback and editing for style [6] [5] https://review.openstack.org/#/c/453262/ [6] https://review.openstack.org/#/c/473620/ Discussion also continues on John Garbutt's resolution on ensuring that decisions are globally inclusive. At this stage it should probably be turned into a guiding principle, and a chapter in the Project Team Guide. Please see: * Decisions should be globally inclusive [7] [7] https://review.openstack.org/#/c/460946/ The following changes are also still in open discussion, although they should probably have a new patchset published to take into account the most recent feedback: * Declare plainly the current state of PostgreSQL in OpenStack [8] * Describe what upstream support means [9] [8] https://review.openstack.org/427880 [9] https://review.openstack.org/440601 Finally, we also have a number of topics being brainstormed openly on the mailing list. One is about replacing TC/UC side workgroups with common SIGs [10], another is around finding a new leader for the Stewardship WG [11], another about allowing teams to use their channel for meetings [12], and the last one about dealing with the confusion around "hosted" projects [13]. Please chime in if you have a strong opinion one way or another: [10] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118723.html [11] http://lists.openstack.org/pipermail/openstack-dev/2017-June/119068.html [12] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118899.html [13] http://lists.openstack.org/pipermail/openstack-dev/2017-June/119043.html == Voting in progress == Flavio's proposed addition to the top-5 wanted list is still missing a couple of votes: * Add "Glance Contributors " to top-5 wanted list [14] [14] https://review.openstack.org/#/c/474604/ == TC member actions for the coming week(s) == flaper87 to update "Drop Technical Committee meetings" with a new revision sdague or dirkm to post a new patchset on the database support resolution, to address formatting issues dims to sync with Stackube on progress and report back We also need to find volunteers for the champion role in the proposed (and already-approved) Pike goals. Please add your name on those if you're willing to spearhead the effort on those. == Need for a TC meeting next Tuesday == We could have used a meeting next week to discuss the next steps in the vision if there were enough people interested in that. With July 4th it's however unlikely that our usual meeting datetime would work for that. I suggest we discuss it during the office hours or asynchronously on the #openstack-tc channel instead. Cheers! -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"
Fox, Kevin M wrote: > [...] > So whats really unclear to end users is that when they talk about a piece of > "openstack" they may be talking about a great many things: > 1. is it managed under the 4 opens > 2. is it in github.com/openstack. > 3. is it under openstack governance. > 4. is it an 'openstack project' (what does this mean anymore. I thought that > was #3, but maybe not?) > 5. is "openstack" part of its title > > Is a project part of openstack if it meets one of those? all of them? or some > subset? If we can't answer it, I'm not sure users will ever understand it. We can totally answer it. The "official" answer is (3) (synonymous to (4)). The trick is, the project list on our governance website is a *lot* less visible than (2) or (5), so it's very easy to appear as an openstack project while not being one. Which is precisely the confusion I'd like us to clear out one way or another. My initial suggestion (on the other thread) was to give some brand name to things that are hosted/companion/friends/neighbors/stackforge, so that we can more easily apply that mark and incrementally reduce the confusion. The thread went on discussing other corrective measures at the edge (like turning github.org/openstack into more curated content, and/or removing the openstack/ prefix from all of our repositories). All good suggestions. This thread introduced yet another possibility: no longer accept hosting for projects outside of openstack governance. This clarifies things a lot, but presents challenges of its own, as that space was pretty convenient to bootstrap projects or host companion projects, as well as build a community. -- Thierry Carrez (ttx) __ 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
[openstack-dev] [release] Release countdown for week R-8 and R-7, June 30 - July 14
Welcome to our regular release countdown email! Development Focus - Teams should be wrapping up library work in preparation for release deadlines, starting R-6 week. General Information --- A number of libraries and projects following the cycle-with-intermediary model still haven't released anything in Pike. We recommend that you produce at least one release before the corresponding deadline (Jul 13 for non-client libs, Jul 20 for client libs, Aug 10 for other deliverables), so that the release team has something to fall back to when release branches need to be cut. If no Pike release was produced by the deadline, the release team will have to trigger a release at the current master HEAD, which is almost certainly not what you want. The following deliverables are still concerned: Jul 13: glance-store, instack, requestsexceptions Jul 20: python-designateclient, python-searchlightclient, python-swiftclient Aug 10: aodh, bifrost, ceilometer, cloudkitty[-dashboard], magnum[-ui], murano-agent, networking-hyperv, panko, senlin-dashboard, tacker Actions --- If your team has a contributor whose work is not reflected in commit authorship (or only appear as "Co-Authored-By" in commit messages), they won't get the right to vote for upcoming elections, unless you explicitly add them to the "extra-atc" list for your project. Please review your contributors and submit patches to the openstack/governance repository (reference/projects.yaml file) accordingly. The deadline for submitting those requests is July 13 ! For projects following the cycle-with-milestones release model, pre-release branches will be cut at RC1, and only members of the $PROJECT-release group in Gerrit will be able to approve backports for further RCs. In preparation for that release phase, you should review who is in that group and adjust it accordingly. Projects (especially those following stable policy) should also review their stable branches and trigger stable point releases as necessary to ship the backports that have landed on those branches, if any. Upcoming Deadlines & Dates -- Extra-ATC addition deadline: July 13 Non-client libraries final releases: July 20 Client libraries final releases: July 27 Pike-3 milestone (and Feature freeze): July 27 Final Pike release: August 30 Queens PTG in Denver: Sept 11-15 -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"
Monty Taylor wrote: > I also continue to challenge the assertion. There are dead projects in > there for sure- but there are a LOT of non-dead live projects. It's not > like we have 6 live and 6 dead projects. The overwhelming majority of > the projects are not dead. Early results on my analysis says otherwise... Although it's far from complete I would say about half of them haven't been touched over the past year. Feel free to help classifying them at: https://etherpad.openstack.org/p/negative-space-analysis -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"
Jimmy McArthur wrote: > Thierry Carrez wrote: >> The confusion I'm talking about is not the passive-aggressive from >> people involved in openstack. It's from our prospective new users, who >> have no idea about our governance, making random searches on Google. >> It's from people getting hit by marketing message from projects claiming >> to be official OpenStack projects, while they are not. It's extremely >> difficult for those to see clearly, especially with all our online >> presence reinforcing the confusion. > > If there is specifically confusion around Google searches, I'd suggest > as a first step to spend some time working on redirects for dead > projects and very clearly updating documentation. For all of Google's > magic, there are some simple and easy rules to help correct bad search > data. Unfortunately, those pages just exist -- those hundreds of projects projects might be inactive, they still have git repositories and wiki pages. We could more actively clean them up (and then yes, adjusting the corresponding Google juice), but (1) we don't really have any right to do so unless we get permission (which is hard to get from dead projects), and (2) that's a giganormous amount of maintenance work. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"
James E. Blair wrote: > Thierry Carrez writes: > >> 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 reason, though. The benefits of >> offering that service are: >> >> 1- it lets us set up code repositories and testing infrastructure before >> a project applies to be an official OpenStack project. >> >> 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 >> environment >> >> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself > > I think this omits what I consider the underlying reason for why we did > it: > > It helps us build a community around OpenStack. > > Early on we had so many people telling us that we needed to support > "ecosystem" projects better. That was the word they used at the time. > Many of us said "hey, you're free to use github" and they told us that > wasn't enough. > > We eventually got the message and invited them in, and it surpassed our > expectations and I think surprised even the most optimistic of us. We > ended up in a place where anyone with an OpenStack related idea can try > it out and collaborate frictionlessly with everyone else in the > OpenStack community on it, and in doing so, become recognized in the > community for that. The ability for someone to build something on top > of OpenStack as part of the OpenStack community has been empowering. > > I confess to being a skeptic and a convert. I wasn't thrilled about the > unbounded additional responsibility when we started this, but now that > we're here, I think it's one of the best things about the project and I > would hate to cleave our community by ending it. I think that's a great point, Jim. I spent a lot of time last week analyzing the "negative space" (things that are on our project infrastructure but are not openstack), and there are indeed a number of projects which would qualify as "companion projects": David's ARA, the swift3 Swift middleware, or Neutron plugins for some proprietary hardware that got kicked out of the Neutron stadium. There aren't so many of those, but keeping those close to us is definitely a good thing. Ideally we would find a way to continue to host those, without creating any doubt as to whether they are an official OpenStack project under TC governance. Such options to address the confusion at the edge exist, and they were explored in the previous thread (selective GitHub replication, aggressive tagging, active removal of obviously-dead things, separate branding/domains...). The main issue being, those options all involved a lot of work for the infra team, work that is not conceivable with its current limited resources. The only reason why I put the nuclear plan B on the table is that we can't get the plan A properly done... -- Thierry Carrez (ttx) __ 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
