Re: [Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] getting back onto our IRC channel
Jeremy Stanley wrote: [...] It does indeed sound like you might be caught up in the aforementioned SASL-only network blacklist (I wasn't even aware of it until this ML thread) which Freenode staff seem to be using to help block the spam onslaught from some known parts of the Internet. [...] Yes, the Freenode blacklist blocks most cloud providers IP blocks. My own instance (running on an OpenStack public cloud) is also required to use SASL. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Vancouver Forum - Post your selected topics now
Hi everyone, You've been actively brainstorming ideas of topics for discussion at the "Forum" at the Vancouver OpenStack Summit. Now it's time to select which ones you want to propose, and file them at forumtopics.openstack.org ! The topic submission website will be open until EOD on Sunday, April 15, at which point the Forum selection committee will take the entries and make the final selection. So you have the whole week to enter your selection of ideas on the website. Thanks ! -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ops Meetup, Co-Location options, and User Feedback
Erik McCormick wrote: > I'm a +1 too as long as the devs at large are cool with it and won't > hate on us for crashing their party. As a data point, in a recent survey 89% of surveyed developers supported that the Ops meetup should happen at the same time and place. Amongst past PTG attendees, that support raises to 92%. Furthermore I only heard good things about the Public Cloud WG participating to the Dublin PTG. So I don't think anyone views it as "their party" -- just as an event where we all get stuff done. -- Thierry ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] IMPORTANT - future of ops meetups!
Chris Morgan wrote: > You've probably see the thread about possibly combining ops meetups > with PTG to make a new broader event. Here is a rough draft of what that > would actually look like: > > *"Monday and Tuesday are cross-project days where ops are welcome to > attend SIG and other discussions, and if not interested can be travel > days or whatever for them. Then Wed-Thurs are the two tracks/events > where the ops folks have what has traditionally been done for ops > meetups. Then Friday is a travel day or ops can stick around to follow > up with dev-side things > that they weren't able to get to over the week or wanted to follow up on."* Yes traditionally we have tried to roughly organize the time, to focus the first two days on horizontal / cross-project / guild / SIG work, and the next three days more on vertical work. But that is more of a rough guideline than a hard rule: the constraints of available space make that division a bit fuzzy. For example in Dublin, Manila has been asking to avoid being scheduled at the same time as Cinder, and got scheduled to Tuesday and Friday. So while it's very likely that the traditional Ops meetup sessions would happen on Wed-Thu, don't plan travel just yet ! Once we know how many rooms we have, which groups want space and for how many days, we'll work on a more precise allocation. > Thanks to Sean McGinnis for proposing this to get the ball rolling. This > would mean there's a "normal" ops meetup for two days on days 3 and 4 of > this combined event, with the option of attending earlier (days 1 and 2) > if you want to contribute to dev/ops/openstack community sessions (e.g. > SIGs), and possibly also staying a 5th day. It's also worth noting that it is possible for groups to book additional meeting spots outside the pre-allocated time and space. If some work groups realize they would like to meet on Monday to get work done, that's definitely possible. It all appears on the dynamic event schedule to make it easy to see what's going on. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Vancouver Forum - Topic submission tool is now open!
Hi everyone, The Forum in Vancouver is getting closer! As a reminder, the Forum is where we take advantage of having a large community presence at the Summit to discuss and get wide feedback on a variety of topics around the future of OpenStack and adjacent projects. Starting today, our submission tool is open for you to submit abstracts for the most popular sessions that came out of your brainstorming. All teams, work groups and SIGs should now submit their abstracts at: http://forumtopics.openstack.org/ before 11:59PM UTC on Sunday April 15th! We are looking for a good mix of project-specific, cross-project or strategic/whole-of-community discussions, and sessions that emphasis collaboration between our various types of contributors are most welcome! We assume that anything submitted to the system has achieved a good amount of discussion and consensus that it's a worthwhile topic. After submissions close, a team of representatives from the User Committee, the Technical Committee and Foundation staff will take the sessions proposed by the community and fill out the schedule. You can expect the draft schedule to be released around April 22nd. Further details about the Forum can be found at: https://wiki.openstack.org/wiki/Forum Regards, -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ops Meetup, Co-Location options, and User Feedback
Jimmy McArthur wrote: > [...] > We've been meeting regularly with the User Committee to help establish > goals for the Committee as well as Operators and End Users. There are > three critical things that we identified as immediate areas of concern: > > * How to involve operators, end users, and app-devs that are not in > the normal cycle of communications within the community (IRC, MLs, > Summit, Forum, etc..) > * Ensuring a productive communication loop between the User and Dev > communities so feedback from OS Days, local user groups, and Ops > Meetups are communicated and brought to the Forum in a way that > allows developers to address concerns in future release cycles. > * Removing perceived barriers and building relationships between User > and Dev communities ++ Great list! > [...] > Ops 2H 2018 Meetup > In addition to those questions, we'd like to pitch an option for you for > the next Ops Meetup. The upcoming PTG is the week of September 10 in > North America. We have an opportunity to co-locate the Ops Meetup at the > PTG. I think it's generally a good idea, especially for work sessions. The PTG already turned into an event where any group of contributors, whatever their focus is, can meet in person and do some work. We had the Public Cloud WG in Dublin and I feel like they had very productive discussions ! > If the Ops community was interested in this, we would have separate > space with your own work sessions and separate branding for the Ops > attendees. This would also involve updating the language on the > OpenStack website and potentially renaming the PTG to something more > inclusive to both groups. Personally, I'm not a big fan of separate branding (or "co-location"). If the "PTG" name is seen as too developer-centric, I'd rather change the event name (and clearly make it a work event for anyone contributing to OpenStack, whatever the shape of their group). Otherwise we just perpetuate the artificial separation by calling it an ops event co-located with a dev event. It's really a single "contributor" event. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] Poll: S Release Naming
Jens Harbott wrote: > 2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński <sla...@kaplonski.pl>: >> Hi, >> >> Are You sure this link is good? I just tried it and I got info that "Already >> voted" which isn't true in fact :) > > Comparing with previous polls, these should be personalized links that > need to be sent out to each voter individually, so I agree that this > looks like a mistake. We crashed CIVS for the last naming with a private poll sent to all the Foundation membership, so the TC decided to use public (open) polling this time around. Anyone with the link can vote, nothing was sent to each of the voters individually. The "Already voted" error might be due to CIVS limiting public polling to one entry per IP, and a colleague of yours already voted... Maybe try from another IP address ? -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Pointer to the release cycles vs. downstream consuming models PTG discussion summary
Hi! On Tuesday afternoon of the PTG week we had a track of discussions to brainstorm how to better align our release cycle and stable branch maintenance with the OpenStack downstream consumption models. I posted a summary at: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128005.html Happy reading! -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Rocky cycle goals
Hi everyone, In case you missed it, we are at the end of the community goals selection process for the upcoming Rocky cycle. The current selection is a mix of one ops-facing goal (ability to set logs to debug without restarting the service, using mutable configuration), and one dev-facing tech debt reduction goal (going further in getting rid of mox). Emilien posted: > TC voted (but not approved yet) and selected 2 goals that will likely be > approved if no strong voice is raised this week: > > Remove mox > https://review.openstack.org/#/c/532361/ > > Toggle the debug option at runtime > https://review.openstack.org/#/c/534605/ > > If you have any comment on these 2 selected goals, please say it now > otherwise TC will approve it and we'll discuss about details at the PTG. Let us know of any comment. You can find the other proposed goals listed at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ubuntu Kernel with Meltdown mitigation SSL issues
Sam Morrison wrote:
> We updated our control infrastructure to the latest Ubuntu Xenial Kernel
> (4.4.0-109) which includes the meltdown fixes.
>
> We have found this kernel to have issues with SSL connections with python and
> have since downgraded. We get errors like:
>
> SSLError: SSL exception connecting to
> https://keystone.example.com:35357/v3/auth/tokens: ("bad handshake:
> Error([('', 'osrandom_rand_bytes', 'getrandom() initialization failed.')],)”,)
>
> Full trace: http://paste.openstack.org/show/646803/
>
> This was affecting glance mainly but all API services were having issues.
>
> Our controllers are running inside KVM VMs and the guests see the CPU as
> "Intel Xeon E3-12xx v2 (Ivy Bridge)”
>
> This isn’t an openstack issue specifically but hopefully it helps others who
> may be seeing similar issues.
Thanks Sam for sharing! If you can clearly narrow it down to a specific
update (kernel or microcode), can you make sure the bug is reported back
to Ubuntu ?
Distros are struggling with the stability of the Meltdown/Spectre
workarounds (especially the opaque CPU microcode updates) and can
probably use any information we can provide to them.
--
Thierry Carrez (ttx)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] thierry's longer dev cycle proposal
David Medberry wrote: > Just saw some of your comments (great, thanks), and I'll weigh in if I > come up with a cogent input. > > I'd really like to see Bloomberg, RAX, and Cirrus7, Huawei, and other > ops folks respond. > > I suspect this is already a fait accompli but there are many details (as > you mentioned already in one posting about mid-cycles) to work out. It's not really fait accompli, it's just a proposal up for discussion at this stage. Which is the reason why I started the thread on -dev -- to check the sanity of the change from a dev perspective first. If it makes things harder and not simpler on that side, I don't expect the TC to proceed. While it may have desirable side-effects on the ops side (something I'm not convinced of), the main reason for it is imho to align our rhythm with our current development pace / developer capabilities. I felt like we were self-imposing too many deadlines, events and coordination processes for limited gain. Maybe I'm wrong though :) -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] Ops Meetups team minutes + main topics
David Medberry wrote: > I think the Foundation staff were very very wary of extending the PTG or > doing dual sites simultaneously due to not saving a thing logistically. > Yes, it would conceivably save travel for folks that need to go to two > separate events (as would the other colo options on the table) but not > saving a thing logistically over two separate events as we have now. A > six or seven day sprint/thing/ptg would also mean encroaching on one or > both weekends (above and beyond travel dates) and that may really limit > venue choices as private parties (weddings, etc) tend to book those > locales on weekends. We also need to be careful with not restoring issues we had with the old-style Design Summit. We want to avoid creating conflicts that would reduce the productivity of the PTG (so running in parallel would be dangerous). We also want to make sure the PTG remains a work event rather than a feedback gathering event, as the start of the cycle is not the best moment to introduce new priorities. That timing resulted in a lot of frustration in the past. Running the Ops meetup on the last days of the week before is one option. That would let organizations save a bit on travel for people that want to attend both (although hotel costs would increase with the stay-over-weekend). My personal objection to that is that my brain usually shuts down after 5 days of intense work, so I'm not looking forward to that long week (or I would skip the Ops meetup to focus on the PTG). More generally I think we need to have that discussion in the broader context of our event portfolio. What is the best way to have Ops meetups in 2018, with increased participation from ops in Forums at summits and OpenStack Days ? I feel like smaller, local events like OpenStack Days were quite successful in reaching out to the silent majority of our users that would not travel to a twice-a-year Ops Meetup. Should we encourage more of that ? The Public Cloud WG/SIG managed to hold discussions at various OpenStack Days as well... So we could encourage having ops-centric discussions around local OpenStack Days, and then use Forums at Summits as the funnel to close the feedback loop in those discussions. That would reduce the need for a "big" twice-a-year Ops Meetup and let us piggyback on already organized events... Just thinking out loud... -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Openstack-sigs] [QA] Proposal for a QA SIG
Rochelle Grober wrote: > Thierry Carrez wrote: >> One question I have is whether we'd need to keep the "QA" project team at >> all. Personally I think it would create confusion to keep it around, for no >> gain. >> SIGs code contributors get voting rights for the TC anyway, and SIGs are free >> to ask for space at the PTG... so there is really no reason (imho) to keep a >> "QA" project team in parallel to the SIG ? > > Well, you can get rid of the "QA Project Team" but you would then need to > replace it with something like the Tempest Project, or perhaps the Test > Project. You still need a PTL and cores to write, review and merge tempest > fixes and upgrades, along with some of the tests. The Interop Guideline > tests are part of Tempest because being there provides oversight on the style > and quality of the code of those tests. We still need that. SIGs can totally produce some code (and have review teams), but I agree that in this case this code is basically a part of "the product" (rather than a tool produced by guild of practitioners) and therefore makes sense to be kept in an upstream project team. Let's keep things the way they are, while we work out other changes that may trigger other organizational shuffles (like reusing our project infrastructure beyond just OpenStack). I wonder if we should not call the SIG under a different name to reduce the confusion between QA-the-project-team and QA-the-SIG. Collaborative Testing SIG? -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [QA] Proposal for a QA SIG
Andrea Frittoli wrote: > [...] > during the last summit in Sydney we discussed the possibility of creating an > OpenStack quality assurance special interest group (OpenStack QA SIG). > The proposal was discussed during the QA feedback session [0] and it > received > positive feedback there; I would like to bring now the proposal to a larger > audience via the SIG, dev and operators mailing lists. > [...] I think this goes with the current trends of re-centering upstream "project teams" on the production of software, while using SIGs as communities of practice (beyond the governance boundaries), even if they happen to produce (some) software as the result of their work. One question I have is whether we'd need to keep the "QA" project team at all. Personally I think it would create confusion to keep it around, for no gain. SIGs code contributors get voting rights for the TC anyway, and SIGs are free to ask for space at the PTG... so there is really no reason (imho) to keep a "QA" project team in parallel to the SIG ? In the same vein we are looking into turning the Security project team into a SIG, and could consider turning other non-purely-upstream teams (like I18n) in the future. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases
John Dickinson wrote: > What I heard from ops in the room is that they want (to start) one > release a year who's branch isn't deleted after a year. What if that's > exactly what we did? I propose that OpenStack only do one release a year > instead of two. We still keep N-2 stable releases around. We still do > backports to all open stable branches. We still do all the things we're > doing now, we just do it once a year instead of twice. I started a thread around this specific suggestion on the -sigs list at: http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000149.html Please continue the discussion there, to avoid the cross-posting. If you haven't already, please subscribe at: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases
I suggested by Rocky, I moved the discussion to the -sigs list by posting my promised summary of the session at: http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000148.html Please continue the discussion there, to avoid the cross-posting. If you haven't already, please subscribe at: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases
Rochelle Grober wrote: > Folks, > > This discussion and the people interested in it seem like a perfect > application of the SIG process. By turning LTS into a SIG, everyone can > discuss the issues on the SIG mailing list and the discussion shouldn't end > up split. If it turns into a project, great. If a solution is found that > doesn't need a new project, great. Even once there is a decision on how to > move forward, there will still be implementation issues and enhancements, so > the SIG could very well be long-lived. But the important aspect of this is: > keeping the discussion in a place where both devs and ops can follow the > whole thing and act on recommendations. That's an excellent suggestion, Rocky. Moving the discussion to a SIG around LTS / longer-support / post-EOL support would also be a great way to form a team to work on that. Yes, there is a one-time pain involved with subscribing to the -sigs ML, but I'd say that it's a good idea anyway, and this minimal friction might reduce the discussion to people that might actually help with setting something up. So join: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs While I'm not sure that's the best name for it, as suggested by Rocky let's use [lts] as a prefix there. I'll start a couple of threads. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] Upstream LTS Releases
Erik McCormick wrote: > This morning at the Sydney Summit we had a very well attended and very > productive session about how to go about keeping a selection of past > releases available and maintained for a longer period of time (LTS). > > There was agreement in the room that this could be accomplished by > moving the responsibility for those releases from the Stable Branch > team down to those who are already creating and testing patches for > old releases: The distros, deployers, and operators. > > The concept, in general, is to create a new set of cores from these > groups, and use 3rd party CI to validate patches. There are lots of > details to be worked out yet, but our amazing UC (User Committee) will > be begin working out the details. I took the action of summarizing the discussion in more detail, will do as soon as my brain is not as mushy, which might take a couple of weeks :) Note that it's not really about devs vs. ops, with devs abdicating all responsibility on stable branches : it's about allowing collaboration on patches beyond EOL (which is what we are able to support with "live" stable branches on evolving OS/PyPI substrate) and enable whoever steps up to maintain longer-lived branches to come up with a set of tests that actually match their needs (tests that would be less likely to bitrot due to changing OS/PyPI substrate). A number of people from all backgrounds volunteered to flesh out a more detailed proposal. Watch that space! -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [User-committee] [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs
Blair Bethwaite wrote: > There is a not insignificant degree of irony in the fact that this > conversation has splintered so that anyone only reading > openstack-operators and/or user-committee is missing 90% of the > picture Maybe I just need a new ML management strategy. That irony is not lost on me, and no ML management strategy can help. Currently for a ops+dev discussion we have 4 options: start it on -dev (miss ops), start it on -ops (miss devs), cross-post (and miss random messages that are lost as subscribers don't match, or people don't reply to both), or try to post separate variants (but then you have to follow both ends, and your replies miss half the audience). We tried the 4th option this time -- was a fail but then there are no good option in the current setup. Setting up a common ML for common discussions (openstack-sigs) will really help, even if there will be some pain setting them up and getting the right readership to them :) -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Turning TC/UC workgroups into OpenStack SIGs
Matt Riedemann wrote: > How does the re-branding or re-categorization of these groups solve the > actual feedback problem? If the problem is getting different people from > different groups together, how does this solve that? For example, how do > we get upstream developers aware of operator issues or product managers > communicating their needs and feature priorities to the upstream > developers? My hope is that specific developers interested in a given use case or a given problem space would join the corresponding SIG and discuss with operators in the same SIG. As an example, imagine an upstream developer from CERN, able to join the Scientific SIG to discuss with operators and users with Scientific/Academic needs of the feature gap, and group with other like-minded developers to get that feature gap collectively addressed. > No one can join all work groups or SIGs and be aware of all > things at the same time, and actually have time to do anything else. > Is the number of various work groups/SIGs a problem? I would not expect everyone to join every SIG. I would actually expect most people to join 0 or 1 SIG. > Maybe what I'd need is an example of an existing problem case and how > the new SIG model would fix that - concrete examples would be really > appreciated when communicating suggested governance changes. > > For example, is there some feature/requirement/issue that one group has > wanted implemented/fixed for a long time but another group isn't aware > of it? How would SIGs fix that in a way that work groups haven't? Two examples: - the "API WG" was started by people on the UC side, listed as a UC workgroup, and wasn't making much progress as it was missing devs. Now it's been reborn as a TC workgroup, led by a couple of devs, and is lacking app user input. Artificial barriers discourage people to join. Let's just call all of them SIGs. - the "Public Cloud WG" tries to cover an extremely important use case for all of OpenStack (we all need successful OpenStack public clouds). However, so far I've hardly seen a developer joining, because it's seen as an Ops group just trying to make requirements emerge. I want the few developers that OVH or CityCloud or other public clouds are ready to throw upstream to use the rebranded "Public Cloud SIG" as a rally point, to coordinate their actions. Because if they try to affect upstream separately, they won't go far, and we badly need them involved. Yes, it's mostly a rebranding exercise, but perception matters. Hope this clarifies, -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Boston Forum Schedule Online
Tim Bell wrote: > Yes, I agree it is difficult… I was asking as there was an option ‘watch > later’ on the summit schedule for the fishbowl sessions. > > The option should probably be removed from the summit schedule web page so > people don’t get disappointed later if that is not too complicated. Good point, I'll see if that mention can be swiftly removed. -- Thierry ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Boston Forum Schedule Online
Tim Bell wrote: > Do you know if the Forum sessions will be video’d? As far as I know they won't (same as old Design/Ops summit sessions). It's difficult to produce, with people all over the room and not necessarily using microphones. The idea is to have the moderator post a follow-up thread for each session, summarizing the outcome and opening up the discussion to everyone who could not be present in person for one reason or another. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [User-committee] Boston Forum - Formal Submission Now Open!
Eoghan Glynn wrote: > Thanks for putting this together! > > But one feature gap is some means to tag topic submissions, e.g. > tagging the project-specific topics by individual project relevance. > That could be a basis for grouping topics, to allow folks to better > manage their time during the Forum. > > (e.g. if someone was mostly interested in say networking issues, they > could plan to attend all the neutron- and kuryr-tagged topics more > easily if those slots were all scheduled in a near-contiguous block > with minimal conflicts) That is a good point! The tooling we are using this time is pretty basic (a resurrection of good old odsreg for submission / selection, with manual scheduling to the summit scheduling system in the end), and we'll certainly improve it for future Forums. For this first one, we'll likely rely on the Forum selection committee to add the relevant tags when they manually schedule the session. It's probably doable since there are a lot less sessions (only 3 parallel Forum rooms * 4 days compared to the ~20 * 5 we had in "Design Summits"). So if you have specific attendance needs that should be tagged in a session, I encourage you to mention it in the description, for them to pick it up at scheduling time. Also, once the schedule is up, if you see a missing tag, feel free to reach out to them so that they add it. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] What would you like in Pike?
Matt Riedemann wrote: > I just read through the blog post [1] about the upcoming Forum at the > summit. That might help things, at least that's the intent so I'd hope > it helps. We have had design summit sessions in the past where the nova > team asks for feedback from operators/users but those were generally not > well attended (we might get a handful of people). I had assumed the low > attendance was mostly due to scheduling conflicts and people just had > other places to be or more important sessions to attend, which is > understandable when you're trying to pack it all in at the summit. > > [1] http://superuser.openstack.org/articles/openstack-forum/ Yes, that is precisely the intent. Pike is arguably a bit transitional, since we won't have a "Forum" happening before the PTG, but that should be the last such cycle. In future cycles we'll be able to have those "what would you like to see in the next release" discussions at the Forum, in time for us to discuss them, turn them into priority blueprints and community goals, and solve last questions / start working on them at the PTG. So I'm very happy that Melvin started this "mini-Forum" thread to compensate while we transition to the new layout :) -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Subscribe to release-announces to get future OpenStack release announcements !
Hi everyone, As OpenStack produces more deliverables (and some projects do frequent intermediary releases within the cycle), release announcements have been creating a lot of noise on the openstack-announce and openstack-dev mailing-lists, sometimes creating distraction away from more important announcements, or discouraging people to subscribe. In order to cut that noise while preserving that information, the release team proposed[1] to create a specific mailing-list for release announcements, distinct from openstack-announce (now limited to key announcements) and openstack-dev (now limited to development discussion). [1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106579.html So if you are interested in directly receiving release announcements in the future, please subscribe to: http://lists.openstack.org/cgi-bin/mailman/listinfo/release-announce To reduce noise, the list is set up by default to send only one email per day (digest mode) with all the release announcements of that day. If you would like to switch to receiving release announces immediately (one email per announcement), just switch the "Set Digest Mode" option to "Off" in your subscription options. This list will start to be used for release announcements starting Monday, November 21. PS: if you're not currently subscribed to openstack-announce, please consider joining it. Starting next week, it will only be used for major announcements for the OpenStack Community (one release announce email per cycle at the end of the release, urgent security advisories, election announcements, etc...) and be very low-traffic again. You can find it here: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce Regards, -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [MassivelyDistributed] bi-weekly meeting - Timeslot ?
Thierry Carrez wrote: > lebre.adr...@free.fr wrote: >> After Thierry's cleaning, the possibilities are the following ones: >> >> Wednesday 14 UTC (odd week) >> Wednesday 17 UTC >> Thursday 14 UTC (odd week) >> Thursday 16 UTC (even week) >> Thursday 17 UTC (even week) > > Thursday 15 UTC is also an option. > > Also note that Thursday 14 UTC is currently taken. Trying to free up the > slot with https://review.openstack.org/#/c/395509 but they may want to > keep it. A slot just opened for Wednesday 15 UTC, so I revived your original proposal[1]. If you're still interested in that one let me know and I'll approve the change. https://review.openstack.org/#/c/393899 -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [MassivelyDistributed] bi-weekly meeting - Timeslot ?
lebre.adr...@free.fr wrote: > After Thierry's cleaning, the possibilities are the following ones: > > Wednesday 14 UTC (odd week) > Wednesday 17 UTC > Thursday 14 UTC (odd week) > Thursday 16 UTC (even week) > Thursday 17 UTC (even week) Thursday 15 UTC is also an option. Also note that Thursday 14 UTC is currently taken. Trying to free up the slot with https://review.openstack.org/#/c/395509 but they may want to keep it. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [MassivelyDistributed] bi-weekly meeting
Thierry Carrez wrote: > [...] > That said, it's a balancing act and we may be past the point when > scheduling pain takes over the need to spread meetings out. I'll do a > quick pass to try to free up slots taken by dead meetings, and if we > can't free enough slots we'll likely add a new meeting channel. I did a quick pass and proposed to remove 6 meetings that happen in heavily-demanded slots but did not occur for the last 3 months (or more): https://review.openstack.org/#/q/topic:nov2016-cleanup With those gone I would argue we don't need to add another meeting room. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [MassivelyDistributed] bi-weekly meeting
Blair Bethwaite wrote: > Devil's advocate - what is "full enough"? Surely another channel is > essentially free and having flexibility in available timing is of utmost > importance? See http://docs.openstack.org/project-team-guide/open-community.html#public-meetings-on-irc That said, it's a balancing act and we may be past the point when scheduling pain takes over the need to spread meetings out. I'll do a quick pass to try to free up slots taken by dead meetings, and if we can't free enough slots we'll likely add a new meeting channel. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] 2017 Openstack Operators Mid-Cycle Meetups - venue selection etherpads
Jesse Keating wrote: > This has been my experience as well. I purposefully attend the project > fishbowl sessions and often the project mid cycles to be able to provide > real time operator feedback as future plans are discussed and > retrospectives from the previous release are held. Note that Fishbowl sessions, discussion of future plans and retrospectives from the previous release will be held at the Forum. The PTG will be workroom sessions (without a preset schedule) and focused on immediate implementation plans. Operators are welcome to join (especially if they feel part of a specific upstream project team and used to attend that team midcycles) but should probably prioritize attending the Summit (Forum) and ops midcycle(s) events. > Given a choice between attending either the Ops mid cycle or the PTG, I > see far more value in the PTG, which will be held at a very similar time. I doubt there will be more value for you in the PTG, but to open options for those who want to attend everything, I guess it wouldn't hurt to place them on separate weeks. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] yahoo bounces from this list
Saverio Proto wrote: > everytime I send an email to the list I get back two emails with the > following content: > > mani...@yahoo-inc.com is no longer with Yahoo! Inc. > sune...@yahoo-inc.com is no longer with Yahoo! Inc. > > this happens for every other person subscribed to this list ? Maybe we > should unsubscribe these addresses. Who has admin rights ? Tom ? Yes that's Tom, but he is off for the week, so that might take some extra time to be handled. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Collecting our wiki use cases
Thanks to everyone who helped collecting wiki use cases on that etherpad. I tried to categorize the various use cases and I think they fit in 4 categories: 1/ Things that are already in the process of being moved to reference websites or documentation That would be the main "portal" page with its links to all the other websites, the 'How To Contribute' stuff, the information about elections, release naming, User committee governance... 2/ Things that should probably be published elsewhere Sprints, IRC channels, Mailing lists, Board meeting information, Successbot & Statusbot logging pages... 3/ "Cheap websites" for teams, working groups and some events That is the bulk of the remaining use cases. The wiki makes for an easy and immediate way to publish information about a specific team or working group, including specific processes, self-service team signup, additional meeting information... They also work well as quick-and-basic websites for community-led events like the Design Summit or Ops Meetups. 4/ "Etherpad on steroids" - ephemeral slightly richer documents ...where the wiki is used for building very ephemeral documents like meeting agendas, newsletter drafts, sharing pictures While I think we should continue the effort on (1) and (2), we need a long-term wiki-like solution for (3). One interesting aspect of (3) is that all of the content there is clearly linked to a team of people. So it could easily be that team's duty to keep those pages limited in number and updated, reducing the nasty side-effects of stale pages. If the tool supports it, teams could use ACLs and/or have to vet the creation of new pages under their ownership, reducing the spam aspect. One issue with MediaWiki (compared to some other wikis or light publication platforms) is that it's essentially flat, so this "ownership" concept (which helps with keeping spam and staleness under control) is not really baked in. That leaves (4), where using the wiki leads to stale pages with no real author or maintainer being returned in Google searches. I'd argue that unless the document is clearly owned by a team, permanent and maintained up to date, the wiki should not be used. We have etherpads, we have pastebins, we could add others similar tools if those are not sufficient as ephemeral collaborative scratchpads. If we keep that category under a wiki-like platform, that should at least be under some /tmp special category that we would clean up aggressively. Another learning of this exercise is that while some teams definitely rely on the wiki, we have a finite number of cases to handle. So a rip and replace approach is not completely out of question, if we find a better tool and decide that selective content-copy is cleaner and faster than general cleanup + bulk migration. For the immediate future (Newton) we'll likely focus on completing (1), find solutions for (2), and research potential tools for (3) and (4). Thanks again for the feedback! -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Collecting our wiki use cases
Hi everyone, At the beginning of OpenStack we have been using wiki.openstack.org as our default community lightweight information publication platform. There were/are lots of things in there, reference information that a couple people struggled to keep up to date (and non-vandalized), old pages referencing processes or projects long gone, meeting agendas and minutes, etc. That created a mix of up-to-date reference information and completely outdated random information that is confusing to use (especially for newcomers to our community) and that Google search indiscriminately provides links to. Over the last two years, various groups have worked to push reference information out of the wiki, to proper documentation guides (like the infra guide or the project team guide) or to peer-reviewed specific reference websites (like security.o.o or releases.o.o). These efforts to move reference content to other tools and websites where appropriate will continue. There are still a lot of use cases for which the wiki is a good solution, though, and it is likely that we'll need a lightweight publication platform like a wiki to cover those use cases indefinitely. Since it's difficult to have a complete view of what the wiki is currently used for, I'd like to collect information from current wiki users, to make sure we have the complete picture of wiki use cases as we discuss adding new tools to our toolbelt. So, if you use the wiki as part of your OpenStack work, make sure to check if your use case is mentioned on the etherpad at: https://etherpad.openstack.org/p/wiki-use-cases If not, please add your use case, together with the URL of such a wiki page to that etherpad. Thanks in advance, -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-community] Recognising Ops contributions
Jeremy Stanley wrote: On 2016-03-03 10:41:45 -0800 (-0800), Stefano Maffulli wrote: [...] I suggest not to create a separate category, and reuse ATC. Active Technical Contributor always meant to include any contribution of technical nature, including legal, operations, documentation, user stories, etc. Creating a new name risks TLA proliferation (it's a thing) and exacerbate the "us vs them" that already exists. ATCs would already know that they are operators, doc writers, UX experts, marketers, translators, developers, laywers etc and all have their own venues to meet and discuss among their peers. I agree that we should use a common contributor term for all of them (inclusivity is important and we're all one community), but I actually disagree with our current use of "ATC" for this at all because it's a term defined in the foundation bylaws and, while the people who have "ATC" on their badges and get free conference admission are a _subset_ of the ATC definition in the bylaws, who gets free admission is decided by the conference coordinators on an event-by-event basis and often does not extend to _all_ official ATCs (for example, people with contributions in the prior cycle but not the current cycle are officially ATC but don't get free admission for that). Yeah, we can't really overload ATC because this is defined and used in governance. I'd rather call all of us "contributors". There are "upstream" contributors (people who author changes to the various git repositories that make up OpenStack), and "downstream" contributors (people who help others using OpenStack, by moderating Ops meetups, by filing bugs, by answering questions on Ask, by contributing a blogpost, etc...). Some people contribute both upstream and downstream. Upstream contributors are represented by the Technical Committee and vote for it. Downstream contributors are represented by the User Committee and (imho) should vote for it. If any perks are associated to contribution, they should apply equally to upstream and downstream contributors, because both aspects are equally important. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-tc] [Performance] Where to place OpenStack performance documentation?
Dina Belova wrote: > of course that's possible in future if there will be significant results > and TC will recognise them ;) > > Ok, so I believe we may use Rally as a parent here, I may add new docs > project as a child to Rally in programs.yam :) > If everybody is ok with that, let's do it. I'm fine with that option, but would like to suggest an alternative solution. You could set up a git repository under openstack/* while not being an official team (what used to be "stackforge"). Your work group currently needs a git repository under Gerrit to start working, and it's too early (in terms of team results) to apply to be an official team. Just setting up the git repo under the OpenStack infrastructure sounds like a reasonable solution ? -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-tc] [Performance] Where to place OpenStack performance documentation?
Dina Belova wrote: > the main issue is to publish docs somewhere people will be easily able > to read them and leave feedback on them. So just repository with the > docs is not enough (wherever to place it, openstack/* is cool), we need > a place to publish them. And as I understand, we need some excuse to > publish the docs to the docs.openstack.org <http://docs.openstack.org> - > like being now part of 'Rally' program. OK, sounds good as a workaround solution :) -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Operational Director?
Edgar Magana wrote: > Is the Foundation aware of that? I mean you comment about "It's the > cumulative voting system that is broken” > > Maybe this is a good opportunity for fixing it! Oh sure, it's a well-known issue, which (as far as I know) is periodically discussed by the Board of Directors. It's not trivial to fix (since the election system is obviously pretty deeply embedded in the bylaws). -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Operational Director?
matt wrote: > it's a voted position. there just aren't that many operators who vote > compared to devs and other contributors. to say nothing of > non-contributors who sign up for accounts to vote for their co-workers. It wouldn't be as much of an issue if we used Condorcet or STV -- I would expect operators to be fairly consensual candidates and get elected. It's the cumulative voting system that is broken :) -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [tags] Results of PAO Ops Meeting
Tom Fifield wrote: > A quick update from our tags team meeting in Palo Alto last month. > [...] > 1) Containerizable - new tag Great idea, and having downstream assess that is certainly the best approach. > [...] > 3) "works in rally" - new tag suggestion > > There was general interest in asking the Rally team to consider making a > "works in rally" tag, since the rally tests were deemed 'good'. This one is part of a larger family of tags describing cross-project support (like "has an horizon plugin", or "has heat teamplates") that we started to work on on the upstream side as well. Those would be simple yes/no binary tags, and maintained by the related project team directly. Do you expect the "works in rally" answer to be more complex than a binary yes/no ? Do you think the tag should be maintained by operators rather than directly by the Rally project team ? If not, it's probably fine to get that one defined as other upstream-maintained tags in the same family. Cheers, -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [Openstack] Rescinding the M name decision
Adam Lawson wrote: The alternative of course is to just number the releases since names ultimately don't mean anything but it seems there are problems with that level of simplicity. I personally prefer Tristan's suggestion to keep it as simple as possible. In a few years we'll run out of letters anyway. Part of the confusion here is that we are not naming releases. We are naming release *cycles*. We are giving a name to a period of time, basically. In that period of time, various version numbers for various components will be released. Saying Glance 12.0.0 was released in OpenStack 13 cycle is not really helping. We won't run out of letters, because the names can cycle back to A (potentially using a new theme, away from geographic features near where the corresponding design summit happened). So while we could technically name a release cycle 14, I feel it's a bit more difficult to rally around a number than a name. Also, numbers wouldn't really solve the perceived issues with names: numbers happen to also be culturally meaningful. You don't have a 13th floor in many US buildings. In China, building miss the 4th floor instead. 9 is feared in Japan. And don't talk about 39 to Afghans. I think growing up is accepting the pain that comes with picking a good name, rather than sidestepping the issue. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [tags] Ops-Data vs. Ops-Tags
Subbu Allamaraju wrote: Thierry, Thanks for clarifying in your replies to me and Maish: 1. Who is providing is not the issue, but the what is being provided is. 2. Irrespective of who is providing, there are two types of data - binary and structured. Given this, I don’t think there is any reason not to converge into a single framework where both types of data are accommodated. Right, a single project metadata framework which provides tags and structured data (open to suggestion on how to better call that) about OpenStack projects. Cheers, -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [tags] Ops-Data vs. Ops-Tags
Subbu Allamaraju wrote: Pardon me for being blunt, but I’m still confused why cycles are being spent on semantic wrangling. As you rightly point out, the term is subjective, and that’s the point. Is there a fear a single set of tags that include both dev and operational aspects confuse consumers of OpenStack? Please clarify. No, the fear is that if we provide two types of data (a binary and a dictionary) and call both of them tags, then people will start calling them TC tags (the binary things) and Ops tags (the dictionary things), and that confusion will follow. Confusion will be even deeper once the TC starts to define TC tags based on data from Ops tags. At that point tag won't mean anything anymore. Let me reverse the question: Pardon me for being blunt, but I'm still confused why you insist on calling tags data that cannot be represented as a label and therefore doesn't meet the general usage of the tag word in our industry ? Why not use another word (data, information, dictionary, documentation...) ? I totally get that you want to define operational information under your own terms and don't want to limit yourself to the framework the TC proposed. I just don't get why you want to reuse the exact same word for it. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [tags] Ops-Data vs. Ops-Tags
Subbu Allamaraju wrote: People will starting calling tc this and uc that only if we present two sets of data. I think the right question to ask is why not present one unified set, which was my original understanding when I read your proposal last year. Subbu, It was indeed our proposal -- provide data under the same framework. However, the ops workgroup decided to provide a totally different type of information that the TC provides, using its own framework. I totally respect your right to do that. But that created, in effect, two different sets. I still think we can consider those two sets two different types of data provided under the same project metadata program. But they are different types of data. You build complex objective dictionaries of information around themes. We subjectively define precise labels that apply or do not apply. Calling them the same won't make them magically the same. It will just confuse people. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [tags] Ops-Data vs. Ops-Tags
Hi! As promised in the Tags meeting, I bring the discussion on naming to the list. The OpenStack project structure reform that the Technical Committee drove over the past year introduced two concepts. The first one is the big tent, the idea that we should consider as OpenStack projects all the projects produced by the OpenStack Community in the OpenStack Way and furthering the OpenStack Mission. But as we expand and cover more projects, the picture becomes more confusing to the consumers of this ecosystem. Hence the introduction of a second concept: tags providing clear, actionable information about each project. Tags are a class of metadata[1], a controlled vocabulary of labels. They come with a definition, a set of requirements that a project must fulfill to be granted the label. Ideally the requirements are objective, based on available documentation and metrics. But the tag definition itself remains subjective. [1] https://en.wikipedia.org/wiki/Tag_%28metadata%29 As an example, we wanted to provide actionable information about the long-term survivability of a project to the loss of a given corporate sponsor. We defined a team:diverse-affiliation tag, based on a set of contributor demographics requirements, evaluated using Stackalytics metrics. A project meeting the criteria gets the tag. A project not meeting the criteria doesn't get the tag. A simple, binary label, this is what tags are. At the mid-cycle meetup we engaged with the Ops community to get them involved in the definition of operational tags. But as the workgroup started to work, it focused on defining and providing operational data about each project. The state of docs. The state of packaging. The state of deployment. The concepts being defined, and the nature of the data being built, was quite different from tags. It looked more like structured documentation than like labels. Then yesterday I had a revelation. Tags are a second-order construct. You can't define tags or labels out of the blue. You can only define them using existing metrics or documentation as base data. On the development side, we have plenty of data available, so we jumped directly to defining tags. On the operational side though, the base data still needs to be built. It is extremely valuable data. And it is a prerequisite for any operational label. As an example, take the state of packaging (currently proposed under ops:packaged). Which components are packaged ? What is the quality of that packaging ? There is no clear data on it so far, it needs to be gathered and maintained. If we ever want to define a well-packaged label, we need that information gathered and available. So I would like to take a step back and really consider ops-data and tags as two separate, but complementary concepts. Operational data about projects is a necessary first step if we ever want to define operational tags. You should definitely not limit yourself to the tag framework, and define the best ways to gather and convey that information. As a second step, someone may propose tags based on that operational data (I have a few ideas there already), but that is really a second step. That doesn't mean we can't display operational data on the official website describing projects. If the Foundation staff sees value in displaying that information on www.openstack.org, it can certainly be displayed, in parallel to the labels/tags. In conclusion, I'd like to suggest that you find an better name to describe this operational data about projects, because calling them tags or labels will be confusing in this two-step picture. My personal suggestion would be ops-data, but I don't really care which color you paint that bikeshed (as long as it's not blue!). Thanks for reading so far, hoping we can work within the same framework to communicate the best information to all the consumers of our ecosystem. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [ops][tags][packaging] ops:packaging tag - a little common sense, please
Jay Pipes wrote: [...] = Packaging tags should be release-specific, or they will be wrong = For these packaging tags, the release must be part of the tag itself, otherwise the information it denotes would be indeterminate. As an example, suppose you have a tag that looks like this: ops:packaged:centos:good And in the tag definition you say that the tag is applied to projects that have CentOS RPM packages available within the last 6 months. Well, as you all know, packages are published for a *particular release of OpenStack*. So, if Nova is tagged with ops:packaged:centos:good in, say, August 2015, the tag would ostensibly be saying that packages exist for Nova in Kilo. However, once November rolls around, and packages for Liberty don't (yet) exist, are you going to remove this ops:packaged:centos:good tag from Nova or (worse) change it to ops:pacakged:centos:no? Instead, have the tag be specific to a release of OpenStack: packaged:centos:kilo There is a provision in the tag framework for (secondary) attributes. So far we only used it to track the since when information on the integrated-release legacy tag. If packaging basically carries over, the only interesting bit of information is what is the first release cycle the packaging appeared in, so you could actually have: - repo: openstack/nova tags: - name: packaged:centos since: diablo I think it's easier and simpler to maintain. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Tags] Tags Team Repo our first tags!
Jesus M. Gonzalez-Barahona wrote: Given that tags have a clear binary value, and that some people have expressed the convenience of having some more information available, maybe the tags could be just the result of applying certain conditions to a more complex description of a metric or set of metrics. Right, and that's was I was hinting at in another thread where I said we could totally define tags on top of Ops-provided more complex data. I think the key thing to recognize here is that tags mean a precise thing (i.e. just a label), and that the Ops Tag WG is actually interested in providing a richer data set around specific operator-impacting areas. One option is to abandon the idea and converge to using the same concept. Another option is to rename that rich data (project operational metadata ?) to avoid the confusion of calling with same name what is essentially two different things. That will open the door to defining tags on top of it. And if the ops WG is only interested in publishing the complex metadata, I guess a workgroup around the TC could take up the work of turning that data into a set of tags. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Tags] Tags Team Repo our first tags!
Stefano Maffulli wrote: On 06/02/2015 07:54 AM, Jay Pipes wrote: Please, no. We should not have ops tags that are different than other tags for no good reason. Let me put it another way: I think there is a good reason for Operators to look for information about a project that is more descriptive than the current definition of project tags. Whether the tags can be expanded or if a different approach is needed to display such information I don't know. I would expect operators to be interested to know the details of what 'is-packaged' mean: are packages available in my favorite distro? how often are they built? If that information is not in the tag itself, then it should be visible somewhere else. It's visible in the tag description. Each tag is backed by a precise definition that explains what the tag means. Tags as designed are labels, not metrics. We define what well-packaged means, and then apply that label to projects that fit the bill. If we mix the messaging by making tags be both labels and metrics, then it will be extra-hard to make a project navigation website to expose both. That said, the Ops tags WG is pretty much on the same line -- the discussion we had in Vancouver was that we should define subjectively what well-packaged means, and than apply it objectively. Same for the other ops tags. So I think we are actually on the same line... -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] No longer doing stable point releases discussion on openstack-dev
Hi Ops, I just started a wider discussion about the proposal we made in Vancouver to stop doing stable point releases in the future, which can be TL;DR: as: - We propose to stop tagging coordinated point releases (like 2015.1.1) - We continue maintaining stable branches as a trusted source of stable updates for all projects though In the spirit of avoiding cross-posting and broken threads, I invite you to read the post at: http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html You can either comment there or on the thread here. I'll follow both. Cheers, -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
