Re: [openstack-dev] [all] We're combining the lists!
Robert Collins wrote: > There don't seem to be any topics defined for -discuss yet, I hope > there will be, as I'm certainly not in a position of enough bandwidth > to handle everything *stack related. > > I'd suggest one for each previously list, at minimum. As we are ultimately planning to move lists to mailman3 (which decided to drop the "topics" concept altogether), I don't think we planned to add serverside mailman topics to the new list. We'll still have standardized subject line topics. The current list lives at: https://etherpad.openstack.org/p/common-openstack-ml-topics -- 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] Asking for suggestion of video conference tool for team and webinar
Trinh Nguyen wrote: I tried several free tools for team meetings, vPTG, and webinars but there are always drawbacks ( because it's free, of course). For example: * Google Hangout: only allow a maximum of 10 people to do the video calls * Zoom: limits about 45m per meeting. So for a webinar or conference call takes more than 45m we have to splits into 2 sessions or so. If anyone in the community can suggest some better video conferencing tools, that would be great. So we can organize better communication for our team and the community's webinars. Jitsi meet is an open source + free as in beer solution based on WebRTC: https://meet.jit.si/ No account needed, no participant limit. -- 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] [publiccloud-wg] Serving vendor json from RFC 5785 well-known dir
Monty Taylor wrote: [...] What if we added support for serving vendor data files from the root of a primary URL as-per RFC 5785. Specifically, support deployers adding a json file to .well-known/openstack/client that would contain what we currently store in the openstacksdk repo and were just discussing splitting out. [...] What do people think? I love the idea of public clouds serving that file directly, and the user experience you get from it. The only two drawbacks on top of my head would be: - it's harder to discover available compliant openstack clouds from the client. - there is no vetting process, so there may be failures with weird clouds serving half-baked files that people may blame the client tooling for. I still think it's a good idea, as in theory it aligns the incentive of maintaining the file with the most interested stakeholder. It just might need some extra communication to work seamlessly. -- 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][release] Document deliverables without release management
Hi, The Release Management team is handling release management for deliverables from all official OpenStack teams. However, there are a number of exceptions: - deliverables that are not using tags or branches for their 'release', or that are directly published (docs, specs, cookiecutters...) - deployment deliverables that are released on a specific marketplace (Chef supermarket, Charm store...) and that are not relying on the OpenStack release management team help To facilitate tracking the intention of the teams for their deliverables, I proposed the following change: https://review.openstack.org/#/c/613268/ It introduces a "release-management:" key to the deliverable entries in the governance projects.yaml file that lists official repos. By default (if the key is not present), the deliverable would be handled by the OpenStack Release Management team using the openstack/release repository. This change applies the key to already-known exceptions: please review those and suggest any other exception that I missed! 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-job-failures] Release of openstack-infra/shade failed
Tony Breeds wrote: AFACIT the upload was successful: shade-1.27.2-py2-none-any.whl : 2018-10-24T03:20:00 d30a230461ba276c8bc561a27e61dcfd6769ca00bb4c652a841f7148a0d74a5a shade-1.27.2-py2.py3-none-any.whl : 2018-10-24T03:20:11 8942b56d7d02740fb9c799a57f0c4ff13d300680c89e6f04dadb5eaa854e1792 shade-1.27.2.tar.gz: 2018-10-24T03:20:04 ebf40040b892f3e9bd4229fd05fff7ea24a08c51e46b7f2d8b3901ce34f51cbf Yes the release is up on Pypi and on releases.o.o, so I think we are good. The strange thing is that the tar.gz was uploaded *befoer* the wheel even though our publish jobs explictly do it in the other order and the timestamp of the tar.gz doesn't match the error message. The timestamps don't match, but in the logs the tar.gz is uploaded last, as designed... Where did you get the timestamps from ? If from Pypi maybe their clocks are off or they do some kind of processing that affects the timestamp... -- 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] [api] Paste Maintenance
Ed Leafe wrote: On Oct 15, 2018, at 7:40 AM, Chris Dent wrote: I'd like some input from the community on how we'd like this to go. I would say it depends on the long-term plans for paste. Are we planning on weaning ourselves off of paste, and simply need to maintain it until that can be completed, or are we planning on encouraging its use? Agree with Ed... is this something we plan to minimally maintain because we depend on it, something that needs feature work and that we want to encourage the adoption of, or something that we want to keep on life-support while we move away from it? My assumption is that it's "something we plan to minimally maintain because we depend on it". in which case all options would work: the exact choice depends on whether there is anybody interested in helping maintaining it, and where those contributors prefer to do the 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] [tc] bringing back formal TC meetings
Ghanshyam Mann wrote: On Fri, 05 Oct 2018 02:47:53 +0900 Jeremy Stanley wrote > On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote: > [...] > > TC members, please reply to this thread and indicate if you would > > find meeting at 1300 UTC on the first Thursday of every month > > acceptable, and of course include any other comments you might > > have (including alternate times). > > This time is acceptable to me. As long as we ensure that community > feedback continues more frequently in IRC and on the ML (for example > by making it clear that this meeting is expressly *not* for that) > then I'm fine with resuming formal meetings. +1. Time works fine for me, Thanks for considering the APAC TZ. I agree that we should keep encouraging the usual discussion in existing office hours, IRC or ML. I will be definitely able to attend other 2 office hours (Tuesday and Wednesday) which are suitable for my TZ. 1300 UTC is obviously good for me, but once we are off DST that will mean 5am for our Pacific Time people (do we have any left ?). Maybe 1400 UTC would be a better trade-off? Regarding frequency, I agree with mnaser that once per month might be too rare. That means only 5-ish meetings for a given a 6-month membership. But that can work if we use the meeting as a formal progress status checkpoint, rather than a way to discuss complex topics. -- 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 model for feature-complete OpenStack libraries
Hi everyone, In OpenStack, libraries have to be released with a cycle-with-intermediary model, so that (1) they can be released early and often, (2) services consuming those libraries can take advantage of their new features, and (3) we detect integration bugs early rather than late. This works well while libraries see lots of changes, however it is a bit heavy-handed for feature-complete, stable libraries: it forces those to release multiple times per year even if they have not seen any change. For those, we discussed[1] a number of mechanisms in the past, but at the last PTG we came up with the conclusion that those were a bit complex and not really addressing the issue. Here is a simpler proposal. Once libraries are deemed feature-complete and stable, they should switch them to an "independent" release model (like all our third-party libraries). Those would see releases purely as needed for the occasional corner case bugfix. They won't be released early and often, there is no new feature to take advantage of, and new integration bugs should be very rare. This transition should be definitive in most cases. In rare cases where a library were to need large feature development work again, we'd have two options: develop the new feature in a new library depending on the stable one, or grant an exception and switch it back to cycle-with-intermediary. If one of your libraries should already be considered feature-complete and stable, please contact the release team to transition them to the new release model. Thanks for reading! [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131341.html -- The Release Team __ 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][castellan] Time for a 1.0 release?
Ade Lee wrote: On Tue, 2018-09-25 at 16:30 -0500, Ben Nemec wrote: Doug pointed out on a recent Oslo release review that castellan is still not officially 1.0. Given the age of the project and the fact that we're asking people to deploy a Castellan-compatible keystore as one of the base services, it's probably time to address that. To that end, I'm sending this to see if anyone is aware of any reasons we shouldn't go ahead and tag a 1.0 of Castellan. + 1 +1 Propose it and we can continue the discussion on the review :) -- 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-sigs] [goals][tc][ptl][uc] starting goal selection for T series
First I think that is a great goal, but I want to pick up on Dean's comment: Dean Troyer wrote: [...] The OSC core team is very thin, yes, it seems as though companies don't like to spend money on client-facing things...I'll be in the hall following this thread should anyone want to talk... I think OSC (and client-facing tooling in general) is a great place for OpenStack users (deployers of OpenStack clouds) to contribute. It's a smaller territory, it's less time-consuming than the service side, they are the most obvious interested party, and a small, 20% time investment would have a dramatic impact. It's arguably difficult for OpenStack users to get involved in "OpenStack development": keeping track of what's happening in a large team is already likely to consume most of the time you can dedicate to it. But OSC is a specific, smaller area which would be a good match for the expertise and time availability of anybody running an OpenStack cloud that wants to contribute back and make OpenStack better. Shameless plug: I proposed a Forum session in Berlin to discuss "Getting OpenStack users involved in the project" -- and we'll discuss such areas that are a particularly good match for users to get 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] [storyboard] Prioritization?
Ben Nemec wrote: On 9/25/18 3:29 AM, Thierry Carrez wrote: Absence of priorities was an initial design choice[1] based on the fact that in an open collaboration every group, team, organization has their own views on what the priority of a story is, so worklist and tags are better ways to capture that. Also they don't really work unless you triage everything. And then nobody really looks at them to prioritize their work, so they are high cost for little benefit. So was the storyboard implementation based on the rant section then? Because I don't know that I agree with/understand some of the assertions there. First, don't we _need_ to triage everything? At least on some minimal level? Not looking at new bugs at all seems like the way you end up with a security bug open for two years *ahem*. Not that I would know anything about that (it's been fixed now, FTR). StoryBoard's initial design is definitely tainted by an environment that has changed since. Back in 2014, most teams did not triage every bug, and were basically using Launchpad as a task tracker (you created the bugs that you worked on) rather than a bug tracker (you triage incoming requests and prioritize them). Storyboard is therefore designed primarily a task tracker (a way to organize work within teams), so it's not great as an issue tracker (a way for users to report issues). The tension between the two concepts was explored in [1], with the key argument that trying to do both at the same time is bound to create frustration one way or another. In PM literature you will even find suggestions that the only way to solve the diverging requirements is to use two completely different tools (with ways to convert a reported issue into a development story). But that "solution" works a lot better in environments where the users and the developers are completely separated (proprietary software). [1] https://wiki.openstack.org/wiki/StoryBoard/Vision [...] Also, like it or not there is technical debt we're carrying over here. All of our bug triage up to this point has been based on launchpad priorities, and as I think I noted elsewhere it would be a big step backward to completely throw that out. Whatever model for prioritization and triage that we choose, I feel like there needs to be a reasonable migration path for the thousands of existing triaged lp bugs in OpenStack. I agree, which is why I'm saying that the "right" answer might not be the "best" answer. -- 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] [storyboard] Prioritization?
Doug Hellmann wrote: I think we need to reconsider that position if it's going to block adoption. I think Ben's case is an excellent second example of where having a field to hold some sort of priority value would be useful. Absence of priorities was an initial design choice[1] based on the fact that in an open collaboration every group, team, organization has their own views on what the priority of a story is, so worklist and tags are better ways to capture that. Also they don't really work unless you triage everything. And then nobody really looks at them to prioritize their work, so they are high cost for little benefit. That said, it definitely creates friction, because alternatives are less convenient / visible, and it's not how other tools work... so the "right" answer here may not be the "best" answer. [1] https://wiki.openstack.org/wiki/StoryBoard/Priority -- 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-sigs] [all][tc] We're combining the lists!
Doug Hellmann wrote: I'm inclined to include it and either use a direct mailing or the [tc] tag on the new discuss list to reach TC members, but I would like to hear feedback from TC members and other interested parties before calling that decision made. Please let me know what you think. +1 -- the separate list has outlived its usefulness. -- 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-schedule] about release Series
Jaze Lee wrote: Hello, Is the content in https://releases.openstack.org/ is the latest? There are some question here, why Queens cycles is longer then Rocy cycles. The Rocy cycles is too shot of live, even less than six month? May be the "estimated 2019-02-23" is a slip of pen? Should it be "2020-02-23" ? Can someone tell some reason about this? Thanks a lot. It probably is a slip of pen. Thanks for noticing ! I proposed the fix: https://review.openstack.org/604309 -- 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-sigs] [tc]Global Reachout Proposal
Melvin Hillsman wrote: https://thelounge.chat/ - have not tried it yet but looks promising especially self-hosted option We had a discussion in the infra room on TheLounge: there is a long-standing infra spec request to offer such a service on our project infrastructure, and it would go a long way to solve the "default experience" as it provides a nice UI by default with "always connected" behavior that most people expect from such communication media those days. The main blocker AIUI is to integrate it with some authentication mechanism(s)... -- 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-sigs] [Openstack-operators] [tc]Global Reachout Proposal
Sylvain Bauza wrote: Le mar. 18 sept. 2018 à 14:41, Jeremy Stanley <mailto:fu...@yuggoth.org>> a écrit : On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote: [...] > I can understand that IRC cannot be used in China which is very > painful and mostly it is used weChat. [...] I have yet to hear anyone provide first-hand confirmation that access to Freenode's IRC servers is explicitly blocked by the mainland Chinese government. There has been a lot of speculation that the usual draconian corporate firewall policies (surprise, the rest of the World gets to struggle with those too, it's not just a problem in China) are blocking a variety of messaging protocols from workplace networks and the people who encounter this can't tell the difference because they're already accustomed to much of their other communications being blocked at the border. I too have heard from someone who's heard from someone that "IRC can't be used in China" but the concrete reasons why continue to be missing from these discussions. Thanks fungi, that's the crux of the problem I'd like to see discussed in the governance change. In this change, it states the non-use of existing and official communication tools as to be "cumbersome". See my comment on PS1, I thought the original concern was technical. Why are we discussing about WeChat now ? Is that because a large set of our contributors *can't* access IRC or because they *prefer* any other ? In the past, we made clear for a couple of times why IRC is our communication channel. I don't see those reasons to be invalid now, but I'm still open to understand the problems about why our community becomes de facto fragmented. Agreed, I'm still trying to grasp the issue we are trying to solve here. We really need to differentiate between technical blockers (firewall), cultural blockers (language) and network effect preferences (preferred platform). We should definitely try to address technical blockers, as we don't want to exclude anyone. We can also allow for a bit of flexibility in the tools used in our community, to accommodate cultural blockers as much as we possibly can (keeping in mind that in the end, the code has to be written, proposed and discussed in a single language). We can even encourage community members to reach out on local social networks... But I'm reluctant to pass an official resolution to recommend that TC members engage on specific platforms because "everyone is 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] [tc] notes from stein ptg meetings of the technical committee
Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2018-09-17 17:07:43 -0400: On 09/17/2018 04:50 PM, Doug Hellmann wrote: [...] I don't remember the history quite the way Jay does, either. I remember us trying to base the decision more about what the team was doing than how the code looked or whether the implementation met anyone's idea of "good". That's why we retained the requirement that the project "aligns with the OpenStack Mission". Hmm. I very specifically remember the incubation and graduation review of Zaqar and the fact that over a couple cycles of TC elections, the "advice" given by the TC about specific technical implementation details changed, often arbitrarily, depending on who was on the TC and what day of the week it was. In fact, I pretty vividly remember this arbitrary nature of the architectural review being one of the primary reasons we switched to a purely objective set of criteria. I remember talking about objectivity, but I also remember that we stopped reviewing aspects of a project like it's architecture or implementation details to avoid having the case you describe recur. I remember that because I had a hard time coming around to that point of view, at first. You're correct, however, that the resolution we adopted as the first step toward the big tent change (https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html#recognize-all-our-community-is-a-part-of-openstack) does talk about making decisions based on team practices and projects fitting the mission as being objective requirements. And the patch that implemented the first part of the big tent change (https://review.openstack.org/#/c/145740/14) also talks about objectivity. It's interesting that we took different things away from the same discussion. :-) In any case, I think we've learned there is still quite a bit of subjectivity in the question about whether a project fits the mission. Right. Back then our goal was definitely to remove the most subjective requirements. We removed judgment on whether the project was a good idea, or whether the technical architecture was sound, or whether the project was "mature" enough. We only kept two criteria: alignment with the OpenStack culture, and alignment with the OpenStack mission. Those are not purely objective criteria though. We had cases where we had to do a leap of faith whether the project really aligns with the OpenStack culture. And we had projects that were in a grey area even with our very vague mission statement. The Adjutant discussion, in the end, was about whether it would significantly hurt interoperability, and therefore be detrimental to the OpenStack mission rather than helping 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] [release][searchlight] Need rights to create stable branches and tags
Trinh Nguyen wrote: > Dear Release Management team, > > As we're reaching the Stein-1 milestone, I would like to prepare the > branches and tags. According to the documents, it's the job of the > Release Management team but it also says I as the PTL can do it. I > wonder which is the best way because Searchlight has missed several > milestones. > > It would be great if anyone in the Release Management team can give me > some advice. As PTL, you should request tags (releases) by proposing a change to the openstack/releases repository. The process is explained in https://releases.openstack.org/reference/using.html#requesting-a-release and also in: https://docs.openstack.org/project-team-guide/release-management.html#how-to-release No rights are actually needed, we just check that the requester is the PTL or the designated release liaison before approving the request. Let us know if you have other questions ! -- 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] Open letter/request to TC candidates (and existing elected officials)
Matt Riedemann wrote: > [...] > I want to see the TC be more of a cross-project project management > group, like a group of Ildikos and what she did between nova and cinder > to get volume multi-attach done, which took persistent supervision to > herd the cats and get it delivered. Lance is already trying to do this > with unified limits. Doug is doing this with the python3 goal. I want my > elected TC members to be pushing tangible technical deliverables forward. > > I don't find any value in the TC debating ad nauseam about visions and > constellations and "what is openstack?". Scope will change over time > depending on who is contributing to openstack, we should just accept > this. And we need to realize that if we are failing to deliver value to > operators and users, they aren't going to use openstack and then "what > is openstack?" won't matter because no one will care. > [...] I agree that we generally need more of those cross-project champions, and generally TC members are in a good position to do that kind of work. The TC itself is also in a good position to "bless" those initiatives and give them some amount of priority (with our limited influence). I'm just a bit worried to limit that role to the elected TC members. If we say "it's the role of the TC to do cross-project PM in OpenStack" then we artificially limit the number of people who would sign up to do that kind of work. You mention Ildiko and Lance: they did that line of work without being elected. So I would definitely support having champions to drive SIG cross-project priorities, and use the TC both to support them and as a natural pool of champion candidates -- I would just avoid tying the role to the elected group? -- 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] [election] [tc] thank you
Emilien Macchi wrote: After 2 years at the TC, I feel lucky enough to have been part of this group where I hope that my modest contributions helped to make OpenStack a bit better. I've learnt so many things and worked with a talented group where it's not easy every day, but we have made and will continue to progress in the future. I personally feel like some rotation needs to happen, therefore I won't run the current election. I don't plan to leave or anything, I just wanted to say "merci" to the community who gave me a chance to be part of this team. Thanks for your service, Emilien! Your quality input on both technical and social aspects of the TC activity helped us move forward over those past 2 years. Please consider serving again 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
Re: [openstack-dev] [TC][Searchlight] Searchlight project missing from the OpenStack website
Trinh Nguyen wrote: I'm not sure if I missed something but Searchlight is not listed in the Software section of the OpenStack website [1]. Is it because Searchlight has missed the Rocky cycle? Searchlight appears in "Shared services" at the bottom of: https://www.openstack.org/software/project-navigator/openstack-components#openstack-services 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] Retiring openstack-infra/odsreg and openstack-infra/puppet-odsreg
Andreas Jaeger wrote: Puppet-odsreg is unused nowadays and it seems that odsreg is unused as well. I'll propose changes to retire them with topic "retire-odsreg", So... we actually still used odsreg until recently for Forum submissions. The Berlin Forum is the first one where we won't use it, so I feel it's a bit too early to retire that codebase. If the current plan (which is to reuse the CFP app from the website) does not work, we'd certainly welcome having a plan B. If you REALLY want it gone NOW I guess we could just push it to GitHub and keep it there until we are 100% sure we won't need it anymore, but that sounds a bit silly. -- 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] ptgbot HOWTO
Hi everyone, In a few days some of us will meet in Denver for the 4th OpenStack PTG. The event is made of several 'tracks' (organized around a specific team/group or a specific theme). Topics of discussions are loosely scheduled in those tracks, based on the needs of the attendance. This allows to maximize attendee productivity, but the downside is that it can make the event a bit confusing to navigate. To mitigate that issue, we are using an IRC bot to expose what's happening currently at the event at the following page: http://ptg.openstack.org/ptg.html It is therefore useful to have a volunteer in each room who makes use of the PTG bot to communicate what's happening. This is done by joining the #openstack-ptg IRC channel on Freenode and voicing commands to the bot. How to keep attendees informed of what's being discussed in your room - To indicate what's currently being discussed, you will use the track name hashtag (found in the "Scheduled tracks" section on the above page), with the 'now' command: #TRACK now Example: #swift now brainstorming improvements to the ring You can also mention other track names to make sure to get people attention when the topic is transverse: #ops-meetup now discussing #cinder pain points There can only be one 'now' entry for a given track at a time. To indicate what will be discussed next, you can enter one or more 'next' commands: #TRACK next Example: #api-sig next at 2pm we'll be discussing pagination woes Note that in order to keep content current, entering a new 'now' command for a track will erase any 'next' entry for that track. Finally, if you want to clear all 'now' and 'next' entries for your track, you can issue the 'clean' command: #TRACK clean Example: #ironic clean How to book reservable rooms Like at every PTG, in Denver we will have additional reservable space for extra un-scheduled discussions. In addition, some of the smaller teams do not have any pre-scheduled space, and will solely be relying on this feature to book the time that makes the most sense for them. Those teams are Chef OpenStack (#chef), LOCI (#loci), OpenStackClient (#osc), Puppet OpenStack (#puppet), Release Management (#relmgt), Requirements (#requirements), and Designate (#designate). The PTG bot page shows which track is allocated to which room, as well as available reservable space, with a slot code (room name - time slot) that you can use to issue a 'book' command to the PTG bot: #TRACK book Example: #relmgt book Ballroom C-TueA2 Any track can book additional space and time using this system. All slots are 1h45-long. If your topic of discussion does not fall into an existing track, it is easy to add a track on the fly. Just ask PTG bot admins (ttx, diablo_rojo, infra...) to create a track for you (which they can do by getting op rights and issuing a ~add command). For more information on the bot commands, please see: https://git.openstack.org/cgit/openstack/ptgbot/tree/README.rst -- 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] Bringing the community together (combine the lists!)
Jeremy Stanley wrote: [...] The proposal is simple: create a new openstack-discuss mailing list to cover all the above sorts of discussion and stop using the other four. [...] Also, in case you were wondering, no the irony of cross-posting this message to four mailing lists is not lost on me. ;) As someone who just had to process a dozen of ML moderation requests about non-member posting to lists due to replies to a cross-posted topic, I wholeheartedly support the list merging :) -- 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] [nova] [placement] placement below or beside compute after extraction?
Matt Riedemann wrote: On 8/23/2018 4:00 AM, Thierry Carrez wrote: In the OpenStack governance model, contributors to a given piece of code control its destiny. This is pretty damn fuzzy. Yes, it's definitely not binary. So if someone wants to split out nova-compute into a new repo/project/governance with a REST API and all that, nova-core has no say in the matter? I'd consider the repository split to be a prerequisite. Then if most people working on the nova-compute repository (not just "someone") feel like they are in a distinct group working on a distinct piece of code and that the larger group is not representative of them, then yes, IMHO they can make a case that a separate project team would be more healthy... -- 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] Post-lunch presentations schedule
Hi! The PTG starts in two weeks in Denver! As in Dublin, we'll have some presentations running during the second half of the lunch break in the lunch room. Here is the schedule: Monday: Welcome to the PTG Welcome new teams / Ops meetup, Housekeeping, Community update, Set stage for the week, Present Stein goals (ttx, mnaser, kendallW) Tuesday: Three demo presentations on tools Gertty (corvus), Storyboard (diablo_rojo), and Simplifying backports with git-deps and git-explode (aspiers) Wednesday: Three general talks Release management (smcginnis), Project navigator (jimmymcarthur), and Tech vision statement intro (zaneb, cdent) Thursday: PTG: present and future Our traditional event feedback session, including a presentation of future PTG/summit co-location plans for 2019 (jbryce, ttx) Friday: Lightning talks Fast-paced 5-min segments to talk about anything... Summaries of team plans for Stein encouraged. A presentation of Sphinx in OpenStack by stephenfin will open the show. Hopefully this time we won't have snow disrupting that schedule. 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] [nova] [placement] placement below or beside compute after extraction?
melanie witt wrote: [...] I have been trying to explain why over several replies to this thread. Fracturing a group is not something anyone does to foster cooperation and shared priorities and goals. [...] I would argue that the group is already fractured, otherwise we would not even be having this discussion. In the OpenStack governance model, contributors to a given piece of code control its destiny. We have two safety valves: disagreement between contributors on that specific piece of code are escalated at the PTL level, and disagreement between teams handling different pieces of code that need to interoperate are escalated at the TC level. In reality, in OpenStack history most disagreements were discussed and solved directly between contributors or teams, since nobody likes to appeal to the safety valves. That model implies at the base that contributors to a given piece of code are in control: project teams boundaries need to be aligned on those discrete groups. We dropped the concept of "Programs" a while ago specifically to avoid creating subgroups ruled by larger groups, or artificial domains of ownership. The key issue here is that there is a distinct subgroup within the group. It should be its own team, but it's not. You are saying that keeping the subgroup governed inside the larger group ensures that features that operators and users need get delivered to them. But having a group retaining control over other groups is not how we ensure that in OpenStack -- it's by using the model above. Are you saying that you don't think the OpenStack governance model, where each team talks to its peers in terms of requirements and conflicts between teams may be escalated to the TC if they ever arise, will ultimately ensure that features that operators and users need get delivered to them ? That keeping placement inside Nova governance will yield better results ? -- 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] Redis licensing terms changes
Jimmy McArthur wrote: Hmm... http://antirez.com/news/120 Today a page about the new Creative Common license in the Redis Labs web site was interpreted as if Redis itself switched license. This is not the case, Redis is, and will remain, BSD licensed. However in the fake news era my attempts to provide the correct information failed, and I’m still seeing everywhere “Redis is no longer open source”. The reality is that Redis remains BSD, and actually Redis Labs did the right thing supporting my effort to keep the Redis core open as usually. What is happening instead is that certain Redis modules, developed inside Redis Labs, are now released under the Common Clause (using Apache license as a base license). This means that basically certain enterprise add-ons, instead of being completely closed source as they could be, will be available with a more permissive license. Right, they switched to an open core model, with "enterprise" features moving from open source (AGPL) to proprietary (the so-called Commons clause). So we need to evaluate our use of Redis since: 1/ We generally prefer our default drivers to use truly open source backends (not open core nor proprietary) 2/ I have no idea how usable Redis core is in our use case without the now-proprietary modules (or how usable Redis core will stay in the future now that Redis labs has an incentive to land any "serious" features in the proprietary modules rather than in core). -- 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] [Searchlight] Action plan for Searchlight in Stein
Trinh Nguyen wrote: Here is my proposed action plan for Searchlight in Stein. The ultimate goal is to revive Searchlight with a sustainable number of contributors and can release as expected. [...] Thanks again for stepping up, and communicating so clearly. -- 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] Redis licensing terms changes
Haïkel wrote: I haven't seen this but I'd like to point that Redis moved to an open core licensing model. https://redislabs.com/community/commons-clause/ In short: * base engine remains under BSD license * modules move to ASL 2.0 + commons clause which is non-free (prohibits sales of derived products) Beyond the sale of a derived product, it prohibits selling hosting of or providing consulting services on anything that depend on it... so it's pretty broad. IMHO, projects that rely on Redis as default driver, should consider alternatives (off course, it's up to them). The TC stated in the past that default drivers had to be open source, so if anything depends on commons-claused Redis modules, they would probably have to find an alternative... Which OpenStack components are affected ? -- 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] [nova] [placement] placement below or beside compute after extraction?
Matt Riedemann wrote: [...] Regarding microversions I was mostly thinking of the various times I've been asked in the placement channel if something warrants a microversion or if we can just bug fix it in, like microversion 1.26. I then generally feel like I need to be defensive when I say, "yes it's a behavior change in the API so it should." That makes me question how stringent others would be about upholding interoperability concerns if I weren't around. [...] The issue with that kind of distrust by default is that it's not sustainable... In a large project you can't have every individual review everything because they trust noone else. That is why in OpenStack we instituted a culture of "trust by default, then escalate to PTL or TC if shit ever hits the fan". And the fact is, the PTL (at team level) or the TC (between teams) rarely had to arbitrate conflicts, because there aren't so many conflicts that are escalated rather than solved by consensus at the lower level. Restoring "trust by default" between placement and the rest of Nova seems to be the root of the problem here. In a community, it's generally done by documenting general expectations and shared understandings, so that you create a common culture and trust by default people to apply it. What would you suggest we do to improve that in this specific case? -- 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][Searchlight] Setting up milestones for Searchlight on Launchpad
Trinh Nguyen wrote:
In an effort to get Searchlight back on track, I would like to set up
milestones as well as clean up the incomplete bugs, blueprints etc. on
Launchpad [1] I was added to the Searchlight Drivers team but I still
can not touch the milestone configuration.
As a member of the "maintainer" team in Launchpad you should be able to
register a series ("stein") and then add milestones to that series. You
should see a "Register a series" link under "Series and milestones" at
https://launchpad.net/searchlight
In addition, I would like to move forward with unreviewed patched on
Gerrit so I need PTL privileges on Searchlight project. Do I have to
wait for [2] to be merged?
For the TC to step in and add you to searchlight-core, yes, we'll have
to wait for the merging of that patch.
To go faster, you could ask any of the existing members in that group to
directly add you:
https://review.openstack.org/#/admin/groups/964,members
(NB: this group looks like it should be updated :) )
--
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] [kolla][project navigator] kolla missing in project navigator
Eduardo Gonzalez wrote: Hi, effectively kolla-ansible is the deployment tool for container images, and kolla the image artifact builder used by other deployment projects as consumable. In the project navigator wasn't kolla nor kolla-ansible, my bad for not expecifying kolla-ansible as deployment deliverable. OK, so how about we make sure *Kolla-Ansible* is present both in the map and the components list ? -- 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] ?= [kolla][project=?utf-8?q? navigator] kolla missing in project navigator
jean-phili...@evrard.me wrote: That second link is very confusing, on the openstack-ansible case. Yes we ship recipes (roles, playbooks) for deployment using Ansible (any other ansible project could use them, maybe we need to adapt there if it's not the case...), but we also deal with the installation and upgrade of the openstack cloud. Therefore, shouldn't OSA also be listed in the "Deployment / Lifecycle Tools"? Yes, the barrier between the two is rather porous. We used to only have TripleO on the other side, but more and more tools (like Charms, Helm) have maintained that their tooling is more than just a pile of recipes. Once we have all that display driven through YAML files stored in a Git repo under Gerrit, we'll be able to fine tune that content, create more subcategories etc. A bit of patience :) -- 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] [kolla][project navigator] kolla missing in project navigator
Eduardo, "Kolla" was originally left out of the map (and therefore the new OpenStack components page) because the map only shows deliverables that are directly usable by deployers. That is why "Kolla-Ansible" is listed there and not "Kolla". Are you making the case that Kolla should be used directly by deployers (rather than run it though Ansible with Kolla-Ansible), and therefore should appear as a deployment option on the map 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
[openstack-dev] [ptg] Register now ! Price increases Wednesday
Hi everyone, If you haven't registered for the PTG in Denver yet, I'd recommend you do it today or tomorrow as the price will switch to last-minute pricing at the end of day on August 22 ! https://www.openstack.org/ptg Protip: There might still be a couple of rooms available in the PTG hotel, but our hotel block closes TODAY. So book now if you want to be at the center of the activity ! -- 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] Who is responsible for the mission and scope of OpenStack?
Chris Dent wrote: In the discussion on a draft technical vision for OpenStack at https://review.openstack.org/#/c/592205/ there is a question about whether the TC is "responsible for the mission and scope of OpenStack". As the discussion there indicates, there is plenty of nuance, but underlying it is a pretty fundamental question that seems important to answer as we're going into yet another TC election period. I've always assumed it was the case: the TC is an elected representative body of the so-called active technical contributors to OpenStack. So while the TC is not responsible for creating the mission from whole cloth, they are responsible for representing the goals of the people who elected them and thus for refining, documenting and caring for the mission and scope while working with all the other people invested in the community. Does anyone disagree? If so, who is responsible if not the TC? A few indications from the bylaws: The TC manages "technical matters relating to the OpenStack Project". The "OpenStack project" is defined as "the released projects to enable cloud computing and the associated library projects, gating projects, and supporting projects". The TC cooperates with the board to apply the OpenStack trademark : it approves components for trademark programs inclusion, and the board decides whether to apply it to those or not. In that sense, the TC is in charge of the "scope" of "OpenStack", since it decides which components may be added to things that bear the "OpenStack" name. But ultimately the board is in charge of the trademark, and not apply it even to things we deem in scope. As far as the mission goes, the bylaws just indicate that the OpenStack project is an "open source cloud computing project". Beyond that, we have an official OpenStack mission statement. In the past, we ruled that this statement was co-owned by the Board and the TC, and that changes to it would need to pass *both* bodies. So I think the answer is... The Board and the TC co-own the mission and the scope of OpenStack. The TC is in charge of the technical side, especially when it comes to implementation. The Board is in charge of the trademark side (it ultimately owns what can be called "OpenStack"). -- 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] New Contributor
Ivoline Ngong wrote: I am Ivoline Ngong. I am a Cameroonian who lives in Turkey. I will love to contribute to Open source through OpenStack. I code in Java and Python and I think OpenStack is a good fit for me. I'll appreciate it if you can point me to the right direction on how I can get started. Hi Ivoline, Welcome to the OpenStack community ! The OpenStack Technical Committee maintains a list of areas in most need of help: https://governance.openstack.org/tc/reference/help-most-needed.html Depending on your interest, you could pick one of those projects and reach out to the mentioned contact points. For more general information on how to contribute, you can check out our contribution portal: https://www.openstack.org/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
Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?
Chris Dent wrote: [...] So my hope is that (in no particular order) Jay Pipes, Eric Fried, Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov, Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to placement whom I'm forgetting [1] would express their preference on what they'd like to see happen. At the same time, if people from neutron, cinder, blazar, zun, mogan, ironic, and cyborg could express their preferences, we can get through this by acclaim and get on with getting things done. [...] I fully support that existing and potential placement contributors decide its destiny. Upstream development work in OpenStack is (currently) organized in "project teams" (groups of people), not programs (domains). If the existing and potential contributors match an existing project team, then work can be placed within it. If it's just a very partial overlap, I'd recommend creating a specific team, especially if placement is expected to attract other contributors. Notes: - the new project team "officialization" can be fast-tracked as this would be a split of official code, not new code - being in separate teams does not prevent cooperation or coordination -- 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] [nova] Rocky blueprint burndown chart
melanie witt wrote: [...] If you have feedback or thoughts on any of this, feel free to reply to this thread or add your comments to the Rocky retrospective etherpad [4] and we can discuss at the PTG. That is great data, thanks for compiling and publishing it ! As far as burndown charts go, it looks healthy (specs getting completed along the way, not approving a lot more than you can actually take). -- 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] PTG Denver Horns
Monty Taylor wrote: On 08/08/2018 09:12 AM, Jeremy Stanley wrote: Speaking of which, is it too soon to put in bids to name the Denver summit and associated release in 2019 "OpenStack Train"? I feel like we're all honorary railroad engineers by now. It seems like a good opportunity to apply the Brian Waldon exception. I'm not even sure we need to apply the Brian Waldon exception, as noisy trains seem to be a permanent geographic feature of Denver. -- 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] Stepping down as coordinator for the Outreachy internships
Victoria Martínez de la Cruz wrote: I'm reaching you out to let you know that I'll be stepping down as coordinator for OpenStack next round. I had been contributing to this effort for several rounds now and I believe is a good moment for somebody else to take the lead. You all know how important is Outreachy to me and I'm grateful for all the amazing things I've done as part of the Outreachy program and all the great people I've met in the way. I plan to keep involved with the internships but leave the coordination tasks to somebody else. Thanks for helping with this effort for all this time ! -- 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
Tony Breeds wrote: 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: [...] Congrats to all, and thank you for stepping up and helping stewarding our various project teams ! -- 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][election] PTL nominations are now closed
Tony Breeds wrote: [...] There are 8 projects without candidates, so according to this resolution[1], the TC will have to decide how the following projects will proceed: Dragonflow, Freezer, Loci, Packaging_Rpm, RefStack, Searchlight, Trove and Winstackers. Here is my take on that... Packaging_Rpm has a late candidate (Dirk Mueller). We always have a few teams per cycle that miss the election call, that would fall under that. Trove had a volunteer (Dariusz Krol), but that person did not fill the requirements for candidates. Given that the previous PTL (Zhao Chao) plans to stay around to help onboarding the new contributors, I'd support appointing Dariusz. I suspect Freezer falls in the same bucket as Packaging_Rpm and we should get a candidate there. I would reach out to caoyuan see if they would be interested in steeping up. LOCI is also likely in the same bucket. However, given that it's a deployment project, if we can't get anyone to step up and guarantee some level of currentness, we should consider removing it from the "official" list. Dragonflow is a bit in the LOCI case. It feels like a miss too, but if it's not, given that it's an add-on project that runs within Neutron, I would consider removing it from the "official" list if we can't find anyone to step up. For Winstackers and Searchlight, those are low-activity teams (18 and 13 commits), which brings the question of PTL workload for feature-complete projects. Finally, RefStack: I feel like this should be wrapped into an Interoperability SIG, since that project team is not producing "OpenStack", but helping fostering OpenStack interoperability. Having separate groups (Interop WG, RefStack) sounds overkill anyway, and with the introduction of SIGs we have been recentering project teams on upstream code production. -- 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] Ongoing spam in Freenode IRC channels
Monty Taylor wrote: [...] However, it's worth noting that matrix is not immune to spam. As an open federated protocol, it's a target as well. Running our own home server might give us some additional tools - but it might not, and we might be in the same scenario except now we're running another service and we had the pain of moving. [...] Any open communication platform is subject to spam. As long as you let anonymous users join and post stuff, it will happen as soon as the platform reaches a certain critical mass. Slack is not immune to this: it has spam too, and the platform being outside of your control limits[1] your options. Freenode/IRC is a bit bad because it does not make it easy to /deal/ with spam. The protocol being designed at a time where it was costly to switch IPs, you can ignore people/hosts, but not messages based on key words. As we look into alternatives, we should evaluate their spam-filtering abilities... [1] https://www.reddit.com/r/Slack/comments/71bd1h/need_help_preventing_pm_spam/ -- 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] Self-healing SIG meeting moved to Thursday morning
Hi! Quick heads-up: Following a request[1] from Adam Spiers (SIG lead), we modified the PTG schedule to move the Self-Healing SIG meeting from Friday (all day) to Thursday morning (only morning). You can see the resulting schedule at: https://www.openstack.org/ptg#tab_schedule Sorry for any inconvenience this may cause. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132392.html -- 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] Post-lunch presentations in Denver
Hi everyone, At the last PTG in Dublin we introduced the concept of post-lunch presentations -- a 30-min segment during the second half of the lunch break during which we communicate and do Q on topics that are generally interesting to a crowd of contributors. In Dublin, you may remember we did a "Welcome to the PTG" session on Monday, a Zuul v3 session on Tuesday and an OpenStackSDK session on Wednesday. Due to the snow storm, we had to cancel the release management presentation on Thursday and the lightning talks scheduled for Friday. We do not *have to* fill every available slot -- but if we find content that is generally useful and can be consumed while people start their digestion process, then we can use one of those slots for that. Interesting topics include development tricks, code review etiquette, new libraries features you should adopt, upgrade horror stories... The content should generally fit within 20 min to leave room for Q If you have ideas, please fill: https://etherpad.openstack.org/p/PTG4-postlunch In a few weeks the TC will review suggestions there and pick things that fit the bill. 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] Stein: a slightly longer release cycle
Hi everyone, As we approach the final stages of the Rocky release, it's time to start planning Stein work. The Stein release schedule is available here: https://releases.openstack.org/stein/schedule.html As discussed[1] during the Vancouver Board+TC+UC meeting, the Foundation will be holding the first PTG in 2019 immediately after the Denver summit in April, 2019 (in the same venue). Since we want to place the PTG close to the cycle start, this results in a slightly-longer release cycle, with the Stein release set to April 10, 2019. That makes Stein 4 weeks longer than Havana or Kilo, our longest cycles so far. That said, with the Berlin summit, Thanksgiving, the long end-of-year holiday break, and Chinese new year, there will be a lot of work time lost during this cycle (like during all of our Northern-hemisphere winter cycles), so the release management team doesn't really expect Stein to feel that much longer, or work planning to be significantly impacted. Cheers, [1] http://lists.openstack.org/pipermail/foundation/2018-June/002598.html -- 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][Election] Last days for PTL nomination
Luke Hinds wrote: On Mon, 30 Jul 2018, 21:19 Jeremy Stanley, <mailto:fu...@yuggoth.org>> wrote: On 2018-07-30 15:23:57 +0700 (+0700), Luke Hinds wrote: > Security is a SIG and no longer a project (changed as of rocky cycle). Technically it's still both at the moment, which is why I proposed https://review.openstack.org/586896 yesterday (tried to give you a heads up in IRC about that as well). A +1 from the current PTL of record on that change would probably be a good idea. I am on PTO for the next two weeks, is +1 in this email ok? I don't have my launchpad credentials with me to SSO login to Gerrit. Sure, I'll reference this email there. Thanks Luke, have a great PTO! -- 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-dev] [trove] Considering the transfter of the project leadership
Dariusz Krol wrote: [...] On the other hand, I can also understand the lack of time to be a PTL since it requires probably a lot of time to coordinate all the work. Let’s wait for Chao Zhao to give his opinion on the topic :) If the PTL delegates the most time-intensive work (release liaison, meeting chair...) then it should not be too much extra work. PTLs are responsible by default for a lot of things in their projects, but all of those things can be delegated to others. -- 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] [self-healing] [ptg] PTG track schedule published
Adam Spiers wrote: Apologies - I have had to change plans and leave on the Thursday evening (old friend is getting married on Saturday morning). Is there any chance of swapping the self-healing slot with one of the others? It's tricky, as you asked to avoid conflicts with API SIG, Watcher, Monasca, Masakari, and Mistral... Which day would be best for you given the current schedule (assuming we don't move anything else as it's too late for that). -- 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] [ptg] PTG track schedule published
Thierry Carrez wrote: Hi everyone, Last month we published the tentative schedule layout for the 5 days of PTG. There was no major complaint, so that was confirmed as the PTG event schedule and published on the PTG website: https://www.openstack.org/ptg#tab_schedule The tab temporarily disappeared, while it is being restored you can access the schedule at: https://docs.google.com/spreadsheets/d/e/2PACX-1vRM2UIbpnL3PumLjRaso_9qpOfnyV9VrPqGbTXiMVNbVgjiR3SIdl8VSBefk339MhrbJO5RficKt2Rr/pubhtml?gid=1156322660=true -- 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] [ptg] PTG track schedule published
Hi everyone, Last month we published the tentative schedule layout for the 5 days of PTG. There was no major complaint, so that was confirmed as the PTG event schedule and published on the PTG website: https://www.openstack.org/ptg#tab_schedule You'll notice that: - The Ops meetup days were added. - Keystone track is split in two: one day on Monday for cross-project discussions around identity management, and two days on Thursday/Friday for team discussions. - The "Ask me anything" project helproom on Monday/Tuesday is for horizontal support teams (infrastructure, release management, stable maint, requirements...) to provide support for other teams, SIGs and workgroups and answer their questions. Goal champions should also be available there to help with Stein goal completion questions. - Like in Dublin, a number of tracks do not get pre-allocated time, and will be scheduled on the spot in available rooms at the time that makes the most sense for the participants. - Every track will be able to book extra time and space in available extra rooms at the event. To find more information about the event, register or book a room at the event hotel, visit: https://www.openstack.org/ptg Note that the second (and last) round of applications for travel support to the event is closing at the end of next week (July 29th) ! Apply if you need financial help attending the event: https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018 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] [stable][meta] Proposing Retiring the Stable Branch project
Tony Breeds wrote: On Fri, Jul 20, 2018 at 01:05:26PM +1000, Tony Breeds wrote: Hello folks, So really the subject says it all. I fell like at the time we created the Stable branch project team that was the only option. Since then we have crated the SIG structure and in my opinion that's a better fit. We've also transition from 'Stable Branch Maintenance' to 'Extended Maintenance' Being a SIG will make it explicit that we *need* operator, user and developer contributions. I meant to say I've created: https://review.openstack.org/584205 and https://review.openstack.org/584206 To make this transition. I think it makes a lot of sense. Stable branch maintenance was always a bit of an odd duck in the project teams (owning no repository), and is technically a downstream activity (post-release) with lots of potential to get users 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] [tc] [all] TC Report 18-26
Zane Bitter wrote: [...] And I'm not convinced that's an either/or choice... I said specifically that it's an either/or/and choice. I was speaking more about the "we need to pick between two approaches, let's document them" that the technical vision exercise started as. Basically I mean I'm missing clear examples of where pursuing AWS would mean breaking vCenter. So it's not a binary choice but it's very much a ternary choice IMHO. The middle ground, where each project - or even each individual contributor within a project - picks an option independently and proceeds on the implicit assumption that everyone else chose the same option (although - spoiler alert - they didn't)... that's not a good place to be. Right, so I think I'm leaning for an "and" choice. Basically OpenStack wants to be an AWS, but ended up being used a lot as a vCenter (for multiple reasons, including the limited success of US-based public cloud offerings in 2011-2016). IMHO we should continue to target an AWS, while doing our best to not break those who use it as a vCenter. Would explicitly acknowledging that (we still want to do an AWS, but we need to care about our vCenter users) get us the alignment you seek ? -- 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 18-26
Finally found the time to properly read this... Zane Bitter wrote: [...] We chose to add features to Nova to compete with vCenter/oVirt, and not to add features the would have enabled OpenStack as a whole to compete with more than just the compute provisioning subset of EC2/Azure/GCP. Could you give an example of an EC2 action that would be beyond the "compute provisioning subset" that you think we should have built into Nova ? Meanwhile, the other projects in OpenStack were working on building the other parts of an AWS/Azure/GCP competitor. And our vague one-sentence mission statement allowed us all to maintain the delusion that we were all working on the same thing and pulling in the same direction, when in truth we haven't been at all. Do you think that organizing (tying) our APIs along [micro]services, rather than building a sanely-organized user API on top of a sanely-organized set of microservices, played a role in that divide ? We can decide that we want to be one, or the other, or both. But if we don't all decide together then a lot of us are going to continue wasting our time working at cross-purposes. If you are saying that we should choose between being vCenter or AWS, I would definitely say the latter. But I'm still not sure I see this issue in such a binary manner. Imagine if (as suggested above) we refactored the compute node and give it a user API, would that be one, the other, both ? Or just a sane addition to improve what OpenStack really is today: a set of open infrastructure components providing different services with each their API, with slight gaps and overlaps between them ? Personally, I'm not very interested in discussing what OpenStack could have been if we started building it today. I'm much more interested in discussing what to add or change in order to make it usable for more use cases while continuing to serve the needs of our existing users. And I'm not convinced that's an either/or choice... -- 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 Update for 3 July
Jeremy Stanley wrote: On 2018-07-04 16:38:41 -0500 (-0500), Sean McGinnis wrote: [...] I would propose based on this lack of feedback that we go back to just having our predesignated office hour times, and anyone interested in catching up on what, if anything, was discussed during office hours can go to the the point in the IRC logs that they are interested in. [...] Heartily seconded. Thirded. Office hours were meant to encourage gathering around specific times (1) to increase the odds of reaching critical mass necessary for discussion, and (2) to ensure presence for outsiders wanting to reach out to the TC. The meeting bot enforces a "start" and an "end" to the discussion. It makes the hour busier. It encourages the discussion to stop rather than to continue outside of the designated times. It discourages random discussions outside the hour (since it won't be logged the same). And imho discourages external questions (since they would be "on the record" and interrupt busy discussions). So yes, I would prefer it to end. Since I don't like to shut down an experiment without proposing something else, here would be my suggestion. I would like to see a middle way between raw logs and meeting reports -- a way to take notes on a discussion channel the same way we document a meeting, but without a start, an end. Automatically producing a report with #info #agree #links every day or week, not changing topics or requiring chairs, or start/endmeeting. Then you get the benefit of a summary (with links to raw logs) without constraining the discussion to specific "hours". If we are good at documenting, it might even reduce the need to read all logs for the channel -- just check the summary for interesting mentions and follow links if interested. The bot could even serve yesterday's report to you in privmsg if you asked for it. That feature would, I believe, be reused in other channels. -- 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 18-26
Zane Bitter wrote: [...] I think if OpenStack wants to gain back some of the steam it had before, it needs to adjust to the new world it is living in. This means: * Consider abolishing the project walls. They are driving bad architecture (not intentionally but as a side affect of structure) In the spirit of cdent's blog post about random ideas: one idea I keep coming back to (and it's been around for a while, I don't remember who it first came from) is to start treating the compute node as a single project (I guess the k8s equivalent would be a kubelet). Have a single API - commands go in, events come out. Right, that's what SIG Node in Kubernetes is focused on: optimize what ends up running on the Kubernetes node. That's where their goal-oriented team structure shines, and why I'd like us to start organizing work along those lines as well (rather than along code repository ownership lines). [...] We probably actually need two groups: one to think about the architecture of the user experience of OpenStack, and one to think about the internal architecture as a whole. I'd be very enthusiastic about the TC chartering some group to work on this. It has worried me for a long time that there is nobody designing OpenStack as an whole; design is done at the level of individual projects, and OpenStack is an ad-hoc collection of what they produce. Unfortunately we did have an Architecture Working Group for a while (in the sense of the second definition above), and it fizzled out because there weren't enough people with enough time to work on it. Until we can identify at least a theoretical reason why a new effort would be more successful, I don't think there is going to be any appetite for trying again. I agree. As one of the very few people that showed up to try to drive this working group, I could see that the people calling for more architectural up-front design are generally not the people showing up to help drive it. Because the reality of that work is not about having good ideas -- "put me in charge and I'll fix everything". It's about taking the time to document it, advocate for it, and yes, drive it and implement it across project team boundaries. It's a lot more work than posting a good idea on an email thread wondering why nobody else is doing it. Another thing we need to keep in mind is that OpenStack has a lot of successful users, and IMHO we can't afford to break them. Proposing incremental, backward-compatible change is therefore more productive than talking about how you would design OpenStack if you started today. -- 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] [ptg] PTG high-level schedule
Hi everyone, In the attached picture you will find the proposed schedule for the various tracks at the Denver PTG in September. We did our best to avoid the key conflicts that the track leads (PTLs, SIG leads...) mentioned in their PTG survey responses, although there was no perfect solution that would avoid all conflicts. If there is a critical conflict that was missed, please let us know, but otherwise we are not planning to change this proposal. You'll notice that: - The Ops meetup team is still evaluating what days would be best for the Ops meetup that will be co-located with the PTG. We'll communicate about it as soon as we have the information. - Keystone track is split in two: one day on Monday for cross-project discussions around identity management, and two days on Thursday/Friday for team discussions. - The "Ask me anything" project helproom on Monday/Tuesday is for horizontal support teams (infrastructure, release management, stable maint, requirements...) to provide support for other teams, SIGs and workgroups and answer their questions. Goal champions should also be available there to help with Stein goal completion questions. - Like in Dublin, a number of tracks do not get pre-allocated time, and will be scheduled on the spot in available rooms at the time that makes the most sense for the participants. - Every track will be able to book extra time and space in available extra rooms at the event. To find more information about the event, register or book a room at the event hotel, visit: https://www.openstack.org/ptg Note that the first round of applications for travel support to the event is closing at the end of this week ! Apply if you need financial help attending the event: https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018 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] [tc] [all] TC Report 18-26
Jay Pipes wrote: [...] I've also argued in the past that all distro- or vendor-specific deployment tools (Fuel, Triple-O, etc [3]) should live outside of OpenStack because these projects are more products and the relentless drive of vendor product management (rightfully) pushes the scope of these applications to gobble up more and more feature space that may or may not have anything to do with the core OpenStack mission (and have more to do with those companies' product roadmap). I totally agree on the need to distinguish between OpenStack-the-main-product (the set of user-facing API services that one assembles to build an infrastructure provider) and the tooling that helps deploy it. The map[1] that was produced last year draws that line by placing deployment and lifecycle management tooling into a separate bucket. I'm not sure of the value of preventing those interested in openly collaborating around packaging solutions from doing it as a part of OpenStack-the-community. As long as there is potential for open collaboration I think we should encourage it, as long as we make it clear where the "main product" (that deployment tooling helps deploying) is. On the other hand, my statement that the OpenStack Foundation having 4 different focus areas leads to a lack of, well, focus, is a general statement on the OpenStack *Foundation* simultaneously expanding its sphere of influence while at the same time losing sight of OpenStack itself I understand that fear -- however it's not really a zero-sum game. In all of those "focus areas", OpenStack is a piece of the puzzle, so it's still very central to everything we do. -- and thus the push to create an Open Infrastructure Foundation that would be able to compete with the larger mission of the Linux Foundation. As I explained in a talk in Vancouver[2], the strategic evolution of the Foundation is more the result of a number of parallel discussions happening in 2017 that pointed toward a similar need for a change: moving the discussions from being product-oriented to being goal-oriented, and no longer be stuck in a "everything we produce must be called OpenStack" box. It's more the result of our community's evolving needs than the need to "compete". [1] http://openstack.org/openstack-map [2] https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/20968/beyond-datacenter-cloud-the-future-of-the-openstack-foundation -- 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] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins
Dmitry Tantsur wrote: [...] My suggestion: tempest has to be compatible with all supported releases (of both services and plugins) OR be branched. [...] I tend to agree with Dmitry... We have a model for things that need release alignment, and that's the cycle-bound series. The reason tempest is branchless was because there was no compatibility issue. If the split of tempest plugins introduces a potential incompatibility, then I would prefer aligning tempest to the existing model rather than introduce a parallel tempest-specific cycle just so that tempest can stay release-independent... I seem to remember there were drawbacks in branching tempest, though... Can someone with functioning memory brain cells summarize them again ? -- 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-sigs] [PTG] Updates!
Doug Hellmann wrote: Are we planning to have space for goal teams to answer implementation questions? At previous PTGs the "goal rooms" ended up not being used (or very very poorly-attended), so our current plan was to not allocate specific space, but leverage the "Ask me anything" project help room to answer those questions as well. It shall be a large room, so plenty of space to do that... and probably nicer compared to waiting in a smaller, dedicated but mostly empty room. That said, if we have people signed up to run a specific room, and people interested in joining that, I'm happy allocating space on Monday or Tuesday for that... Otherwise there is always the option to schedule in reservable space using ptgbot on the fly :) -- 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] [summary] Organizational diversity tag
Neil Jerram wrote: The issue is that the current method (which uses a formula to apply single-vendor and diverse-affiliation tags) is not working so well anymore, with lots of low-activity projects quickly flapping between states. I think you need to explore and state much more explicitly why this is a problem, before you will be able to evaluate possible changes. Right, this was just a summary, we discussed it in more details in the thread and during that Forum session. For example, a single-vendor project would suddenly lose the tag due to a combination of low activity and infra people pushing boilerplate change to their test jobs. Yet the project is still very much single-vendor (and not seeing much activity). The way we ended up working around that in past cycles is by doing a human pass on the calculated results and assess whether the change is more of a data artifact due to low activity, or a real trends. If it was deemed an artifact, we'd not commit that change. But lately most of the changes had to be filtered by a human, which basically makes the calculation useless. One important thing to remember is that the diversity tags are supposed to inform deployers, so that they can make informed choices on which component they are comfortable to deploy. So whatever we come up with, it needs to be useful information for deployers, not just a badge of honor for developers, or a statement of team internal policy. It sounds like this might be part of that 'why'. How sure are you about it? How sure am I about... what? That tags are meant to be useful to deployers and the rest of our downstream consumers ? That is part of the original definition[1] of a tag. The template to define tags even includes a "rationale" section that is meant to justify how the ecosystem benefits from having this tag defined. [1] https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html#provide-a-precise-taxonomy-to-help-navigating-the-ecosystem -- 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] [summary] Organizational diversity tag
Hi! We had a decently-sized thread on how to better track organizational diversity, which I think would benefit from a summary. The issue is that the current method (which uses a formula to apply single-vendor and diverse-affiliation tags) is not working so well anymore, with lots of low-activity projects quickly flapping between states. Suggestions included: - Drop tags, write a regular report instead that can account for the subtlety of each situation (ttx). One issue here is that it's obviously a lot more work than the current situation. - Creating a "low-activity" tag that would clearly exempt some teams from diversity tagging (mnaser). One issue is that this tag may drive contributors away from those teams. - Drop existing tags, and replace them by voluntary tagging on how organizationally-diverse core reviewing is in the team (zaneb). This suggestion triggered a sort of side thread on whether this is actually a current practice. It appears that vertical, vendor-sensitive teams are more likely to adopt such (generally unwritten) rule than horizontal teams where hats are much more invisible. One important thing to remember is that the diversity tags are supposed to inform deployers, so that they can make informed choices on which component they are comfortable to deploy. So whatever we come up with, it needs to be useful information for deployers, not just a badge of honor for developers, or a statement of team internal policy. Thoughts on those suggestions? Other suggestions? -- 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] use of storyboard (was [TC] Stein Goal Selection)
Doug Hellmann wrote: [...] The release team used to (help) manage the launchpad series data. We stopped doing that a long time ago, as Jeremy pointed out, because it was not useful to *the release team* in the way we were managing the releases. We stopped tracking blueprints and bug fixes to try to predict which release they would land in and built tools to make it easier for teams to declare what they had completed through release notes instead. [...] A bit more historical context around that. Launchpad has a design flaw in how it uses milestones and series. Those are used both for pre-milestone planning (what you planned to do) and post-milestone reporting (what actually landed). Since what you plan to do never ends up being what you actually do, using the same fields to track both creates subtle issues. Trust me, I spent my early OpenStack years fighting that discrepancy and trying to provide a "release manager" view of OpenStack with it. As OpenStack grew, the amount of work needed went up and the quality of the result went down. The solution is to use separate tools. Git history and reno are the only accurate way to track what landed. The task tracker should only do pre-milestone planning. Then, what's the best way to track progress toward a milestone ? Launchpad was clearly not the best tool, otherwise we would not have random etherpads with lists of Launchpad links around release candidate time, or people tracking progress in external Trellos. A lot of people wanted more than just binary indicators like tags and milestone targeting. Storyboard is designed to let you use tags, or lists, or boards, whatever the team finds convenient to organize the work. Don't get me wrong, it's not perfect, and it still has much more rough edges than I'd like. But at least it has the potential to become what we need. It doesn't try to do more than it should. It's also worth repeating it is a task tracker, not a product management tool. So yes, you are missing the consistent views of "progress" and "what's landed" across all of OpenStack. But as Jeremy and Doug mentioned, the reality is that we bailed on providing that view through Launchpad a long time ago. -- 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] [release] How to handle "stable" deliverables releases
Hi everyone, As some of the OpenStack deliverables get more mature, we need to adjust our release policies to best handle the case of deliverables that do not need to be updated that much. This discussion started with how to handle those "stable" libraries, but is actually also relevant for "stable" services. Our current models include cycle-tied models (with-intermediary, with-milestones, trailing) and a purely cycle-independent model. Main OpenStack deliverables (the service components that you can deploy to build an OpenStack cloud) are all "released" on a cycle. Libraries are typically maintained per-cycle as well. What happens if no change is pushed to a service or library during a full cycle ? What should we do then ? Options include: 1/ Force artificial releases, even if there are no changes This is the current state. It allows to reuse the exact same process, but creates useless churn and version number confusion. 2/ Do not force releases, but still create branches from latest releases In this variant we would not force an artificial re-release, but we would still create a branch from the last available release, in order to be able to land future patches and do bugfix or security releases as needed. 2bis/ Like 2, but only create the branch when needed Same as the previous one, except that rather than proactively create the stable branch around release time, we'd wait until the branch is actually needed to create it. 3/ Do not force releases, and reuse stable branches from cycle to cycle In this model, if there is no change in a library in Rocky, stable/rocky would never be created, and stable/queens would be used instead. Only one branch would get maintained for the 2 cycles. While this reduces the churn, it's a bit complex to wrap your head around the consequences, and measure how confusing this could be in practice... 4/ Stop worrying about stable branches at all for those "stable" things The idea here would be to stop doing stable branches for those things that do not release that much anymore. This could be done by switching them to the "independent" release model, or to a newly-created model. While good for "finished" deliverables, this option could create issues for things that are inactive for a couple cycles and then pick up activity again -- switching back to being cycle-tied would likely be confusing. My current preference is option 2. It's a good trade-off which reduces churn while keeping a compatibility with the system used for more active components. Compared to 2bis, it's a bit more work (although done in one patch during the release process), but creating the branches in advance means they are ready to be used when someone wants to backport something there, likely reducing process pain. One caveat with this model is that we need to be careful with version numbers. Imagine a library that did a 1.18.0 release for queens (which stable/queens is created from). Nothing happens in Rocky, so we create stable/rocky from the same 1.18.0 release. Same in Stein, so we create stable/stein from the same 1.18.0 release. During the Telluride[1] cycle some patches land and we want to release that. In order to leave room for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, and go directly to 1.20.0. I think we can build release checks to ensure that, but that's something to keep in mind. Thoughts ? [1] It's never too early to campaign for your favorite T name -- 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] proposing changes to the project-team-guide-core review team
Doug Hellmann wrote: > The review team [1] for the project-team-guide repository (managed > by the TC) hasn't been updated for a while. I would like to propose > removing a few reviewers who are no longer active, and adding one > new reviewer. > > My understanding is that Kyle Mestery and Nikhil Komawar have both > moved on from OpenStack to other projects, so I propose that we > remove them from the core team. > > Chris Dent has been active with reviews lately and has expressed > willingness to help manage the guide. I propose that we add him to > the team. > > Please let me know what you think, +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
Re: [openstack-dev] [tc] summary of joint leadership meeting from 20 May
Jay Pipes wrote: > On 06/04/2018 05:02 PM, Doug Hellmann wrote: >> [...]> > Personally, I've very much enjoyed the separate PTGs because I've actually > been able to get work done at them; something that was much harder when the > design summits were part of the overall conference. Right, the trick is to try to preserve that productivity while making it easier to travel to... One way would be to make sure the PTG remains a separate event (separate days, separate venues, separate registration), just co-located in same city and week. > [...] >> There are a few plans under consideration, and no firm decisions >> have been made, yet. We discussed a strawman proposal to combine >> the summit and PTG in April, in Denver, that would look much like >> our older Summit events (from the Folsom/Grizzly time frame) with >> a few days of conference and a few days of design summit, with some >> overlap in the middle of the week. The dates, overlap, and >> arrangements will depend on venue availability. > > Has the option of doing a single conference a year been addressed? Seems > to me that we (the collective we) could save a lot of money not having > to put on multiple giant events per year and instead have one. Yes, the same strawman proposal included the idea of leveraging an existing international "OpenStack Day" event and raising its profile rather than organizing a full second summit every year. The second PTG of the year could then be kept as a separate event, or put next to that "upgraded" OpenStack Day. Thinking on this is still very much work in progress. -- 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] [stable][EM] Summary of forum session(s) on extended maintenance
Hi! We had a double session on extended maintenance at the Forum in Vancouver, here is a late summary of it. Feel free to add to it if you remember extra things. The first part of the session was to present the Extended Maintenance process as implemented after the discussion at the PTG in Dublin, and answer questions around it. The process was generally well received, with question on how to sign up (no real sign up required, just start helping and join #openstack-stable). There were also a number of questions around the need to maintain all releases up to an old maintained release, with explanation of the FFU process and the need to avoid regressions from release to release. The second part of the session was taking a step back and discuss extended maintenance in the context of release cycles and upgrade pain. A summary of the Dublin discussion was given. Some questions were raised on the need for fast-forward upgrades (vs. skip-level upgrades), as well as a bit of a brainstorm around how to encourage people to gather around popular EM releases (a wiki page was considered a good trade-off). The EM process mandates that no releases would be tagged after the end of the 18-month official "maintenance" period. There was a standing question on the need to still release libraries (since tests of HEAD changes are by default run against released versions of libraries). The consensus in the room was that when extended maintenance starts, we should switch to testing stable/$foo HEAD changes against stable/$foo HEAD of libraries. This should be first done when Ocata switches to extended maintenance in August. The discussion then switched to how to further ease upgrade pain, with reports of progress on the Upgrades SIG on better documenting the Fast Forward Upgrade process. We discussed how minimal cold upgrades capabilities should be considered the minimum to be considered an official OpenStack component, and whether we could use the Goals mechanism to push it. We also discussed testing database migrations with real production data (what turbo-hipster did) and the challenges to share deidentified data to that purpose. 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] Organizational diversity tag
amrith.ku...@gmail.com wrote: -Original Message- From: Doug Hellmann Sent: Saturday, June 2, 2018 4:26 PM To: openstack-dev Subject: Re: [openstack-dev] [tc] Organizational diversity tag Excerpts from amrith.kumar's message of 2018-06-02 15:06:27 -0400: Every project on the one-way-trip to inactivity starts with what some people will wishfully call a 'transient period' of reduced activity. Once the transient nature is no longer the case (either it becomes active or the transient becomes permanent) the normal process of eviction can begin. As the guy who came up with the maintenance-mode tag, so as to apply it to Trove, I believe that both the diversity tag and the maintenance mode tag have a good reason to exist, and should both be retained independent of each other. The logic always was, and should remain, that diversity is a measure of wide multi-organizational support for a project; not measured in the total volume of commits but the fraction of commits. There was much discussion about the knobs in the diversity tag measurement when Flavio made the changes some years back. I'm sorry I didn't attend the session in Vancouver but I'll try and tune in to a TC office hours session and maybe get a rundown of what precipitated this decision to move away from the diversity tag. We're talking about how to improve reporting on diversity, not stop doing it. Why not just automate the thing that we have right now and have something kick a review automatically if the diversity in a team changes (per current formula)? That is what we did: get the thing we have right now to propose changes. But we always had a quick human pass to check that what the script proposed corresponded to a reality. Lately (with lower activity in a number of teams), more and more automatically-proposed changes did not match a reality anymore, to the point where a majority of the proposed changes need to be dropped. Example: a low-activity single-vendor project team suddenly loses the tag because one person pushes a patch to fix zuul jobs and another pushes a doc build fix. Example 2: a team with 3 core reveiwers flaps between diverse affiliation and single-vendor depending on who does the core reviewing on its 3 patches per month. Hence the suggestion to either improve our metrics to better support low-activity teams, or switch to a more qualitative/prose report instead of quantitative/tags. -- 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] [DragonFlow][TC] State of the DragonFlow project
Omer Anson wrote: If the issue is just the tagging, I'll tag the releases today/tomorrow. I figured that since Dragonflow has an independent release cycle, and we have very little manpower, regular tagging makes less sense and would save us a little time. Thanks Omer! For tagging, I suggest you use a change proposed to the openstack/releases repository, so that we can test that the release will work. Don't hesitate to ping us on #openstack-releases or read the doc at: http://git.openstack.org/cgit/openstack/releases/tree/README.rst -- 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] A culture change (nitpicking)
Davanum Srinivas wrote: "master should be always deployable and fully backward compatible and so we cant let anything in anytime that could possibly regress anyone" Should we change that attitude too? Anyone agree? disagree? Thanks, Dims I'll definitely jump at this one. I've always thought (and shared on the ML several times now) that our implied but not explicit support for CD from any random commit was a bad thing. While I think it's good to support the idea that master is always deployable, I do not think it is a good mindset to think that every commit is a "release" and therefore should be supported until the end of time. We have a coordinated release for a reason, and I think design decisions and fixes should be based on the assumption that a release is a release and the point at which we need to be cognizant and caring about keeping backward compatibility. Doing that for every single commit is not ideal for the overall health of the product, IMO. It's more than just a CD guarantee, while from a quick glance it would seem like that's the only value it goes much deeper than that. Ensuring that every commit works, is deployable, and maintains backwards compatibility is what enables us to have such a high quality end result at release time. Quite frankly it's looking at every commit as always being a working unit that enables us to manage a project this size at this velocity. Even if people assume no one is actually CDing the projects(which we shouldn't), it's a flawed assumption to think that everyone is running strictly the same code as what's in the release tarballs. I can't think of any production cloud out there that doesn't carry patches to fix things encountered in the real world. Or look at stable maint we regularly need to backport fixes to fix bugs found after release. If we can't rely on these to always work this makes our life much more difficult, both as upstream maintainers but also as downstream consumers of OpenStack. The other aspect to look at here is just the review mindset, supporting every every commit is useable puts reviewers in the mindset to consider things like backwards compatibility and deployability when looking at proposed changes. If we stop looking for these potential issues, we t will also cause many more bugs to be in our released code. To simply discount this as only a release concern and punt this kind of scrutiny until it's time to release is not only going to make release time much more stressful. Also, our testing is built to try and ensure every commit works **before** we merge it. If we decided to take this stance as a community then we should really just rip out all the testing, because that's what it's there to verify and help us make sure we don't land a change that doesn't work. If we don't actually care about that making sure every commit is deployable we are wasting quite a lot of resources on it. "rip out all testing" is probably taking it too far Matt. Instead of perfection when merging, we should look for iteration and reverts. That's what i would like to see. I am not asking for a "Commit-Then-Review" like the ASF. I want us to be just be practical and have some leeway to iterate / update / experiment instead of absolute perfection from all angles. We should move the needle at least a bit away from it. Right... There might be a reasonable middle ground between "every commit on master must be backward-compatible" and "rip out all testing" that allows us to routinely revert broken feature commits (as long as they don't cross a release boundary). To be fair, I'm pretty sure that's already the case: we did revert feature commits on master in the past, therefore breaking backward compatibility if someone started to use that feature right away. It's the issue with implicit rules: everyone interprets them the way they want... So I think that could use some explicit clarification. [ This tangent should probably gets its own thread to not disrupt the no-nitpicking discussion ] -- 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] [tripleo] [barbican] [tc] key store in base services
Ade Lee wrote: [...] So it seems that the two blockers above have been resolved. So is it time to ad a castellan compatible secret store to the base services? It's definitely time to start a discussion about it, at least :) Would you be interested in starting a ML thread about it ? If not, that's probably something I can do :) -- 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][forum] TC Retrospective for Queens/Rocky
Doug Hellmann wrote: [...] I'm missing details and/or whole topics. Please review the list and make any updates you think are necessary. One thing that was raised at the Board+TC+UC meeting is the idea of creating a group to help with wording and communication of "help most needed" list items, so that they contain more business-value explanation and get more regular status updates at the Board... If I remember correctly, Chris Price, dims and you volunteered :) I'm happy to help too. Is that something you would like to track on this document 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] [Infra] Terms of service for hosted projects
Jeremy Stanley wrote: On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: It is my understanding that the infra team will enforce the following conditions when a repo import request is received: * The repo must be licensed under an OSI-approved open source license. That has been our custom, but we should add a statement to this effect in the aforementioned document. * If the repo is a fork of another project, there must be (public) evidence of an attempt to co-ordinate with the upstream first. I don't recall this ever being mandated, though the project-config reviewers do often provide suggestions to project creators such as places in the existing community with which they might consider cooperating/collaborating. Right, that was never a rule (for Stackforge or the current "non-official project hosting" space), and I doubt very much we have enforced it in the past. FWIW we currently host forks of gitdm, gerrit, as well as copies of all sorts of JS code under xstatic-*. That said, I think consulting upstream in case of code copies/forks is a good practice to add in the future. [...] In addition, I think we should require projects hosted on our infrastructure to agree to other policies: * Adhere to the OpenStack Foundation Code of Conduct. This seems like a reasonable addition to our hosting requirements. * Not misrepresent their relationship to the official OpenStack project or the Foundation. Ideally we'd come up with language that they *can* use to describe their status, such as "hosted on the OpenStack infrastructure". Also a great suggestion. We sort of say that in the "what being an unoffocial project is not" bullet list, but it could use some fleshing out. "The OpenStack infrastructure" is likely to be changed in the near future to a more neutral name, but I would keep the "hosted on" language to describe the relationship. -- 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] Organizational diversity tag
Samuel Cassiba wrote: [...] The moniker of 'low-activity' does give the very real, negative perception that things are just barely hanging on. It conveys the subconscious, officiated statement (!!!whether or not this was intended!!!) that nobody in their right mind should consider using the subproject, let alone develop on or against it, for fear that it wind up some poor end-user's support nightmare. [...] Yes, that's fair... and why my original suggestion was to do a (regular) qualitative report that would use words rather than binary tags. -- 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] A culture change (nitpicking)
Jay S Bryant wrote: On 5/29/2018 3:19 PM, Doug Hellmann wrote: Excerpts from Jonathan Proulx's message of 2018-05-29 16:05:06 -0400: On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote: :> >> maybe we're all saying the same thing here? :> > Yeah, I feel like we're all essentially in agreement that nits (of the :> > English mistake of typo type) do need to get fixed, but sometimes :> > (often?) putting the burden of fixing them on the original patch :> > contributor is neither fair nor constructive. :> I am ok with this statement if we are all in agreement that doing :> follow-up patches is an acceptable practice. : :Has it ever not been? : :It seems like it has always come down to a bit of negotiation with :the original author, hasn't it? And that won't change, except that :we will be emphasizing to reviewers that we encourage them to be :more active in seeking out that negotiation and then proposing :patches? Exactly, it's more codifying a default. It's not been unacceptable but I think there's some understandable reluctance to make changes to someone else's work, you don't want to seem like your taking over or getting in the way. At least that's what's in my head when deciding should this be a comment or a patch. I think this discussion suggests for certain class of "nits" patch is preferred to comment. If that is true making this explicit is a good thing becuase let's face it my social skills are only marginally better than my speeling :) -Jon OK, that's all good. I'm just surprised to learn that throwing a follow-up patch on top of someone else's patch was ever seen as discouraged. The spice must flow, Doug Maybe it would be different now that I am a Core/PTL but in the past I had been warned to be careful as it could be misinterpreted if I was changing other people's patches or that it could look like I was trying to pad my numbers. (I am a nit-picker though I do my best not to be. There still seems to be some confusion between "new patchset over existing change" and "follow-up separate change" as to what is the recommended way to fix nits. To clarify, the proposal here is to encourage the posting of a follow-up change. -- 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] Organizational diversity tag
Mohammed Naser wrote: During the TC retrospective at the OpenStack summit last week, the topic of the organizational diversity tag is becoming irrelevant was brought up by Thierry (ttx)[1]. It seems that for projects that are not very active, they can easily lose this tag with a few changes by perhaps the infrastructure team for CI related fixes. As an action item, Thierry and I have paired up in order to look into a way to resolve this issue. There have been ideas to switch this to a report that is published at the end of the cycle rather than continuously. Julia (TheJulia) suggested that we change or track different types of diversity. Before we start diving into solutions, I wanted to bring this topic up to the mailing list and ask for any suggestions. In digging the codebase behind this[2], I've found that there are some knobs that we can also tweak if need-be, or perhaps we can adjust those numbers depending on the number of commits. Right, the issue is that under a given level of team activity, there is a lot of state flapping between single-vendor, no tag, and diverse-affiliation. Some isolated events (someone changing affiliation, a dozen of infra-related changes) end up having a significant impact. My current thinking was that rather than apply a mathematical rule to produce quantitative results every month, we could take the time for a deeper analysis and produce a qualitative report every quarter. Alternatively (if that's too much work), we could add a new team tag (low-activity ?) that would appear for all projects where the activity is so low that the team diversity tags no longer really apply. -- 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] Fast Forward Upgrades (FFU) Forum Sessions
Erik McCormick wrote: > There are two forum sessions in Vancouver covering Fast Forward Upgrades. > > Session 1 (Current State): Wednesday May 23rd, 09:00 - 09:40, Room 220 > Session 2 (Future Work): Wednesday May 23rd, 09:50 - 10:30, Room 220 > > The combined etherpad for both sessions can be found at: > https://etherpad.openstack.org/p/YVR-forum-fast-forward-upgrades You should add it to the list of all etherpads at: https://wiki.openstack.org/wiki/Forum/Vancouver2018 -- 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] [tripleo] [barbican] [tc] key store in base services
Jeremy Stanley wrote:
[...]
As a community, we're likely to continue to make imbalanced
trade-offs against relevant security features if we don't move
forward and declare that some sort of standardized key storage
solution is a fundamental component on which OpenStack services can
rely. Being able to just assume that you can encrypt volumes in
Swift, even as a means to further secure a TripleO undercloud, would
be a step in the right direction for security-minded deployments.
Unfortunately, I'm unable to find any follow-up summary on the
mailing list from the aforementioned session, but recollection from
those who were present (I had a schedule conflict at that time) was
that a Castellan-compatible key store would at least be a candidate
for inclusion in our base services list:
https://governance.openstack.org/tc/reference/base-services.html
Yes, last time this was discussed, there was lazy consensus that adding
"a Castellan-compatible secret store" would be a good addition to the
base services list if we wanted to avoid proliferation of half-baked
keystore implementations in various components.
The two blockers were:
1/ castellan had to be made less Barbican-specific, offer at least one
other secrets store (Vault), and move under Oslo (done)
2/ some projects (was it Designate ? Octavia ?) were relying on advanced
functions of Barbican not generally found in other secrets store, like
certificate generation, and so would prefer to depend on Barbican
itself, which confuses the messaging around the base service addition a
bit ("any Castellan-supported secret store as long as it's Barbican")
--
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] Early bird pricing ends EOD tomorrow, act now
Friendly reminder that the "early bird" pricing for the next PTG in Denver in September is ending at 6:59 UTC Friday (which translates to Thursday, 23:59 Pacific time). If you are concerned with pricing increase and want to snatch the $199 ticket deal before the price jumps to $399, act now ! More details: https://www.eventbrite.com/e/project-teams-gathering-denver-2018-tickets-45296703660 -- 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 18-20
Graham Hayes wrote: Any additional background on why we allowed LCOO to operate like this would help a lot. We can't prevent any group of organizations to work in any way they prefer -- we can, however, deny them the right to be called an OpenStack workgroup if they fail at openly collaborating. We can raise the topic, but in the end it is a User Committee decision though, since the LCOO is a User Committee-blessed working group. Source: https://governance.openstack.org/uc/ -- 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 Update, 14 May
Doug Hellmann wrote: We will also hold a retrospective for the TC as a team on Monday at the Forum. Please be prepared to discuss things you think are going well, things you think we need to change, items from our backlog that you would like to work on, etc. [10] [10] https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21740/tc-retrospective You mean Thursday, right ? -- 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][goals] tracking status of old goals for new projects
Doug Hellmann wrote: There is a patch to update the Python 3.5 goal for Kolla [1]. While I'm glad to see the work happening, the change adds a new deliverable to an old goal, and it isn’t clear whether we want to use that approach for tracking goal work indefinitely. I see a few options. 1. We could update the existing document. 2. We could set up stories in storyboard like we are doing for newer goals. 3. We could do nothing to record the work related to the goal. I like option 2, because it means we will be consistent with future tracking data and we end up with fewer changes in the governance repo (which was the reason for moving to storyboard in the first place). What do others think? I don't have a strong opinion, small preference for (2). At the end of the cycle, the goal becomes just another story with leftover tasks. -- 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] Topics for the Board+TC+UC meeting in Vancouver
Fox, Kevin M wrote:
[...]
Part of the disconnect to me has been that these questions have been left up to
the projects by and large. But, users don't use the projects. Users use
OpenStack. Or, moving forward, they at least use a Constellation. But
Constellation is still just a documentation construct. Not really a first class
entity.
Currently the isolation between the Projects and the thing that the users use, the
Constellation allows for user needs to easily slip through the cracks. Cause
"Project X: we agree that is a problem, but its Y projects problem. Project Y: we
agree that is a problem, but its X projects problem." No, seriously, its OpenStacks
problem. Most of the major issues I've hit in my many years of using OpenStack were in
that category. And there wasn't a good forum for addressing them.
A related effect of the isolation is also that the projects don't work on the
commons nor look around too much what others are doing. Either within OpenStack
or outside. They solve problems at the project level and say, look, I've solved
it, but don't look at what happens when all the projects do that independently
and push more work to the users. The end result of this lack of Leadership is
more work for the users compared to competitors.
[...]
+1
Slicing development along component lines ("project teams") was a useful
construct to absorb all the energy that was sent to OpenStack between
2011 and 2016. But at our current stage (less resources, more users) I
agree that that structure is no longer optimal.
I think we need to start thinking about ways to de-emphasize project
teams (organizing work around code boundaries) and organize work around
goals instead (across code boundaries). A bit like work in Kubernetes is
tracked at SIG level, beyond code ownership. It's not an easy change,
with project teams being so integral to our culture, but it is something
we should start looking into.
--
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] Topics for the Board+TC+UC meeting in Vancouver
Zane Bitter wrote:
> [...]
> How can we avoid (or get out of) the local maximum trap and ensure that
> OpenStack will meet the needs of all the users we want to serve, not
> just those whose needs are similar to those of the users we already have?
It'a a good question, and a topic I raised a couple years ago.
Back then we had (and we arguably still have) a critical mass of
medium-sized private clouds, which makes most contributions gravitate to
that middle area of the potential usage spectrum.
But for the success of OpenStack we need the two extremes to be served:
the "giant public cloud" use case (because we all need that giant public
cloud to burst infinite capacity to in hybrid scenarios), but also the
"lab deployment" use case because that's a great on-boarding tool.
Currently it's still too complex to use OpenStack in those two ends of
the use case spectrum.
How do we solve that ? We can't rely on natural open collaboration
dynamics ("show up and be the change you want to see in the world") --
that one will continue to feed the medium use case. We can continue to
wait for proponents of the "small deployment" or the "massive public
cloud" to suddenly invest hundreds of FTEs to cover their use case. Or
we can be aware of the local maximum trap, go a bit out of our ways to
serve both ends of the spectrum, and realize that it puts us in a lot
better place.
--
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] Etherpad for "Ops/Devs: One community" session
Hi! I have created an etherpad for the "Ops/Devs: One community" Forum session that will happen in Vancouver on Monday at 4:20pm. https://etherpad.openstack.org/p/YVR-ops-devs-one-community If you are interested in continuing breaking up the community silos and making everyone "contributors" with various backgrounds but a single objective, please add to it and join the session ! -- 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, April 27th
Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of currently-considered changes at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recently-approved changes == * New repos: ansible-role-container-registry == Election season == Voting is open to renew 7 seats from the Technical Committee's 13 seats. If you contributed changes recently to any of the official OpenStack repositories, you should have received a ballot. Deadline to vote is 23:59 UTC on Monday, so please vote now ! You can find details on the election at: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129753.html A number of threads have been started to discuss TC-related questions, which may inform your vote: * http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html * http://lists.openstack.org/pipermail/openstack-dev/2018-April/129658.html * http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html * http://lists.openstack.org/pipermail/openstack-dev/2018-April/129664.html == Under discussion == The four changes requiring formal votes from the TC members will be held until the election concludes and new members join: * Splitting/abandoning kolla-kubernetes [1] * Adjutant project team addition [2] * Allow projects to drop py27 support in the PTI [3] * More detail about the expectations we place on goal champions [4] [1] https://review.openstack.org/#/c/552531/ [2] https://review.openstack.org/#/c/553643/ [3] https://review.openstack.org/561922 [4] https://review.openstack.org/564060 == TC member actions/focus/discussions for the coming week(s) == The election closes on Monday. The new members will be inducted, and they will select the Technical Committee chair for the upcoming 6-month session. Urgent topics include preparation of the agenda for the joint Board + TC + UC meeting in Vancouver. If you have an idea of topic that should be discussed, it's still time to chime in on the thread at: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129428.html == 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 Feel free to add your own office hour conversation starter at: https://etherpad.openstack.org/p/tc-office-hour-conversation-starters 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] Summit Forum Schedule
Matt Riedemann wrote: > On 4/25/2018 4:07 PM, Jimmy McArthur wrote: >> Please have a look at the Vancouver Forum schedule: >> https://docs.google.com/spreadsheets/d/15hkU0FLJ7yqougCiCQgprwTy867CGnmUvAvKaBjlDAo/edit?usp=sharing >> (also attached as a CSV) The proposed schedule was put together by two >> members from UC, TC and Foundation. >> >> We do our best to avoid moving scheduled items around as it tends to >> create a domino affect, but we do realize we might have missed >> something. The schedule should generally be set, but if you see a >> major conflict in either content or speaker availability, please email >> speakersupp...@openstack.org. > > Two questions: > > 1. What does the yellow on the pre-emptible instances cell mean? It was two sessions submitted after the deadline that the selection committee decided to keep. Were highlighted yellow so that they could find them. > 2. Just from looking at this, it looks like there were far fewer > submissions for forum topics than actual slots available, so basically > everything was approved (unless it was an obvious duplicate or not > appropriate for a forum session), is that right? Yes, there were less submissions, but they were all actually quite good. Encouraging teams to go through a round of brainstorming before submitting yields a lot less duplicates and crazy sessions. We also had ample space (3 parallel rooms for 4 days, with only one day of keynotes), more than we used to have. We decided to use the 3rd room as a room available to schedule follow-up sessions, in case 40 min does not cut it. More details on that later once the schedule is approved. -- 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-infra] How to take over a project?
Sangho Shin wrote: > Ihar, > > I tried to add netwokring-onos-core group to "Create Reference” permission > using the gerrit UI, and it is registered as a new gerrit review. > But, it seems that it is not a right process, according to the gerrit history > of the similar issues. > Can you please let me know how to change the project ACL? The ACLs are maintained in the openstack-infra/project-config repository. You need to propose a change to the ACL file at: gerrit/acls/openstack/networking-onos.config For more information on how to create and maintain projects, you can read the Infra manual at: https://docs.openstack.org/infra/manual/creators.html While it's geared towards creating NEW projects, the guide can be helpful at pointing to the right files and processes. -- 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] campaign question: How can we make contributing to OpenStack easier?
Fox, Kevin M wrote: > OpenStack has created artificial walls between the various Projects. It shows > up, for example, as holes in usability at a user level or extra difficulty > for operators juggling around so many projects. Users and for the most part, > Operators don't really care about project organization, or ptls, or cores or > such. OpenStack has made some progress this direction with stuff like the > unified cli. But OpenStack is not very unified. I've been giving this some thought (in the context of a presentation I was giving on hard lessons learned from 8 years of OpenStack). I think that organizing development around project teams and components was the best way to cope with the growth of OpenStack in 2011-1015 and get to a working set of components. However it's not the best organization to improve on the overall "product experience", or for a maintenance phase. While it can be confusing, I like the two-dimensional approach that Kubernetes followed (code ownership in one dimension, SIGs in the other). The introduction of SIGs in OpenStack, beyond providing a way to build closer feedback loops around specific topics, can help us tackle this "unified experience" problem you raised. The formation of the upgrades SIG, or the self-healing SIG is a sign that times change. Maybe we need to push in that direction even more aggressively and start thinking about de-emphasizing project teams themselves. -- 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] campaign question: How "active" should the TC be?
Zane Bitter wrote: > [...]> I definitely don't want to get rid of office hours, and I think the > reasons for dropping the meeting (encouraging geographically diverse > participation) are still valid. I'd like to see the TC come up with a > program of work for the term after each Summit, and actively track the > progress of it using asynchronous tools - perhaps Storyboard supported > by follow-ups on the mailing list. FWIW we did translate the work items we discussed in Dublin into a set of StoryBoard stories at: https://storyboard.openstack.org/#!/project/923 But it's pretty recent :) -- 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] campaign question related to new projects
Zane Bitter wrote: > [...] > I would love to see us have a conversation as a community to figure out > what we all, collectively, think that list should look like and document > it. Ideally new projects shouldn't have to wait until they've applied to > join OpenStack to get a sense of whether we believe they're furthering > our mission or not. I agree that we are not really (collectively) taking a step back and looking at the big picture. Forcing myself to work on a map over the past year really helped me reframe how I perceive OpenStack, and I think we should do that sort of exercise more often. What do you think should be the right forum for continuing that discussion? Is that something you think we should discuss at the Forum[tm] ? Or more as an asynchronous discussion at the TC level ? -- 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] campaign question: How should we handle projects with overlapping feature sets?
Rico Lin wrote: > I think we have a start now with providing a decent map to show services > in OpenStack and fill in with projects. What we should have and will be > nice is to ask projects to search through the map (with a brief > introduction of services) when they're registering. To prevent > overlapping from the very beginning seems to be the most ideal, which > might also mean it's actually our responsibility to search through what > exactly a project aims to and what kind of feature it will provide when > we allow people to register a project. I like the idea of asking a new project to tell us where they expect to fit in the OpenStack Map[1]. Projects don't exist in a vacuum and the more they fit in the existing layout / buckets the best the overall "product" (framework of cooperating components) will look. Personally I find that every time I have trouble placing a new project on the map, it's symptomatic of a deeper issue (like unclear scope / usage definition) that needs to be discussed early rather than late. [1] https://www.openstack.org/openstack-map -- 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] Topics for the Board+TC+UC meeting in Vancouver
Doug Hellmann wrote: > Excerpts from Graham Hayes's message of 2018-04-23 15:36:32 +0100: >> I think as an add on to this, would to ask the board to talk to members >> and see what contributions they have made to the technical side of >> OpenStack. >> >> This should not just be Number of commits / reviews / bugs etc but >> also the motivation for the work, e.g. - Feature for a product, bug fix >> found in a product, cross project work or upstream project maintenance. > > A while back Jay Pipes suggested that we ask contributing companies > to summarize their work. I think that was in the context of > understanding what platinum members are doing, but it could apply > to everyone. By leaving the definition of "contribution" open-ended > and asking as a way to celebrate those contributions, we could avoid > any sense of shaming as well as see what the companies consider to > be important. Yes, we discussed this in Sydney and I took the action to try to include it in the Foundation annual report. You can find the result in the Foundation annual report this year: https://www.openstack.org/assets/reports/OpenStack-AnnualReport2017.pdf See pages 7-9. Obviously not optimal (not everybody answered, and some of the responses are a bit off-topic), but we had limited time to pull it off and I think it's a good first step. We can take that as a basis for the next stage of discussion. -- 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] campaign question related to new projects
Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2018-04-22 15:10:40 +0200: >> For the product fit, there is also a lot of room for interpretation. For >> me it boils down to whether "OpenStack" (the product) is better with >> that project "in" rather than with that project "out". Sometimes it's an >> easy sell: if a group wants to collaborate on packaging OpenStack for a >> certain format/distro/deployment tool, it's clearly a win. In that case>> >> more is always better. But in most cases it's not as straightforward. >> There is always tension between added functionality on one side, and >> complexity / dilution / confusion on the other. Every "service" project >> we add makes OpenStack more complex to explain, cross-project work more >> difficult and interoperability incrementally harder. Whatever is added >> has to be damn interesting to counterbalance that. The same goes for > > Why do you think OpenStack has more trouble explaining our feature set > than other cloud systems that have a similarly diverse array of > features? You mean compared to AWS ? It's not the same thing to explain a set of APIs to end users of the cloud and to describe available components to the deployers of the cloud, especially newcomers. For example, Zun API users don't have to know if it relies on Heat, Magnum or Nova to actually do its magic behind the scenes. A Zun deployer absolutely needs to know that. I hope that the Constellation concept will help the latter traverse our product map more efficiently. -- 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] campaign question: How can we make contributing to OpenStack easier?
Doug Hellmann wrote: > Over the last year we have seen some contraction in the number of > companies and individuals contributing to OpenStack. At the same > time we have started seeing contributions from other companies and > individuals. To some degree this contraction and shift in contributor > base is a natural outcome of changes in OpenStack itself along with > the rest of the technology industry, but as with any change it > raises questions about how and whether we can ensure a smooth > transition to a new steady state. > > What aspects of our policies or culture make contributing to OpenStack > more difficult than contributing to other open source projects? > > Which of those would you change, and how? Our focus for the past 7 years was on handling the enormous growth of the OpenStack project. If you asked me in 2010 how many total code contributors we'd have by 2018, my answer would probably have been closer to 700 than to 7000. We've built systems and processes to sustain that growth, and we were very successful at it. The issue is that systems and processes designed to sustain times of inflation do not work so well in a deflation period, or even a stagnation period. It's urgent now to have a critical look at them, see what is useful and what is a scale optimization we could do away with. Our largest reserve of potential contributors lies in the vast number of users we have. In my opinion, one of the mistakes we made was to create an "operators" community separate from the "developers" community, almost in reaction to it. That makes it more difficult to smoothly transition users into contributors and ultimately into code contributions. Melvin and I have been busy over the past two cycles fixing that in various ways, but there is still a lot of work to do. > Where else should we be looking for contributors? Like other large open source projects, OpenStack has a lot of visibility in the academic sector. I feel like we are less successful than others in attracting contributions from there, and we could do a lot better by engaging with them more directly. -- 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] campaign question: How should we handle projects with overlapping feature sets?
Doug Hellmann wrote: > Where do you draw the line at "gratuitous"? The way I interpret "gratuitous" here is: is the new project using a technically-different approach to the same problem, or is it just another group working at the same problem in the same way ? Is the new project just a way to avoid openly collaborating with the existing group ? Is the new project just a way for a specific organization (or group of organizations) to create something they have more control over ? That would be gratuitous duplication, not motivated by a technical reason. We don't really want copies or forks of projects that are just running around the current group in charge. That should be solved at the governance level (and it's the TC's role to address that). > What benefits and drawbacks do you see in supporting multiple tools > with similar features? I touched on that point a bit in my answer on considering new projects. Allowing competition gives you options and lets a thousand flowers bloom, but at the cost of adding complexity / dilution / confusion to the "product" and making interoperability generally more difficult. Generally, the closer to the "core" you are, the less competition you should allow. It's OK to have multiple options for operational tooling or deployment. It's less OK to have two Keystones that every component now needs to be compatible with. Of course teh area between those two extremes is all shades of grey. > How would our community be different, in positive and negative ways, > if we were more strict about avoiding such overlap? I feel like we have been pretty strict with competitive projects. I fear that being stricter would completely close the door to potential evolution. -- 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] campaign question: How "active" should the TC be?
Doug Hellmann wrote: > [...] > Please describe one case where we were either active or reactive > and how that was shown to be the right choice over time. I think that the work on documenting our key principles was proactive, and it really helped to set expectations for new people in our community. > Please describe another case where the choice to be active or > reactive ended up being the wrong choice. The definition of "base services" was also a proactive step, but it failed (so far) to trigger the desired effect (solve the catch-22 around etcd3). > If you think the TC should tend to be more active in driving change > than it is today, please describe the changes (policy, culture, > etc.) you think would need to be made to do that effectively (not > which policies you want us to be more active on, but *how* to > organize the TC to be more active and have that work within the > community culture). Even if the proactive decisions were not all successful, I still think the TC needs to be proactive rather than reactive. We are in a unique position to be able to take a step back and look at the whole picture, rather than look for the dead fish only once you start noticing the smell. We have a few issues that bubbled up that are still unsolved (like the decision on driver teams) which if we had addressed them proactively would likely have been easier. I don't think we need dramatic changes to be able to do active changes effectively. The TC members generally have enough influence to drive that. Some of them are a little shy in using that influence in this way, though, so it ends up falling on the same smaller set of people to burn their influence credit to drive governance change, and that only lasts for so long. So I'd like to see the TC members (and more generally the people interested in governance problems) more active in discovering issues, proactively addressing them and owning the changes. -- 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] campaign question related to new projects
Doug Hellmann wrote: > [This is meant to be one of (I hope) several conversation-provoking > questions directed at prospective TC members to help the community > understand their positions before considering how to vote in the > ongoing election.] > > We are discussing adding at least one new project this cycle, and > the specific case of Adjutant has brought up questions about the > criteria we use for evaluating new projects when they apply to > become official. Although the current system does include some > well-defined requirements [1], it was also designed to rely on TC > members to use their judgement in some other areas, to account for > changing circumstances over the life of the project and to reflect > the position that governance is not something we can automate away. > > Without letting the conversation devolve too much into a discussion > of Adjutant's case, please talk a little about how you would evaluate > a project's application in general. What sorts of things do you > consider when deciding whether a project "aligns with the OpenStack > Mission," for example? Thanks for getting the discussion started, Doug. We have two main criteria in the requirements. The "follows the OpenStack way" one, which I call the culture fit, and the "aligns with the OpenStack mission" one, which I call the product fit. In both cases there is room for interpretation and for personal differences in appreciation. For the culture fit, while in most cases its straightforward (as the project is born out of our existing community members), it is sometimes much more blurry. When the group behind the new project is sufficiently disjoint from our existing team members, you are judging a future promise to behave in "the OpenStack way". In those cases it's really an opportunity to reach out and explain how and why we do things the way we do them, the principles behind our community norms. In the end it's a leap of faith. The line I personally stand on is the willingness to openly collaborate. If the new group is a closed group that has no interest in including new people and wants to retain "control" over the project, and is only interested in the marketing boost of being a part of "OpenStack", then it should really be denied. We provide a space for open collaboration, not for openwashing projects. For the product fit, there is also a lot of room for interpretation. For me it boils down to whether "OpenStack" (the product) is better with that project "in" rather than with that project "out". Sometimes it's an easy sell: if a group wants to collaborate on packaging OpenStack for a certain format/distro/deployment tool, it's clearly a win. In that case more is always better. But in most cases it's not as straightforward. There is always tension between added functionality on one side, and complexity / dilution / confusion on the other. Every "service" project we add makes OpenStack more complex to explain, cross-project work more difficult and interoperability incrementally harder. Whatever is added has to be damn interesting to counterbalance that. The same goes for competitive / alternative projects: in some cases the net result is a win (different approaches to monitoring), while in some cases the net result would be a loss (a Keystone alternative that would make everyone else's life more miserable). In summary while the rules are precise, the way we interpret them can still be varied. That is why this discussion is useful: comparing notes on how we answer that difficult question, understanding where everyone stands, helps us converge to a general consensus of the goals we are trying to achieve when defining "OpenStack" scope, even if we disagree on the particulars. -- 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
