- openstack-discuss - lists.openstack.org

[kolla][tripleo] python3 support for RHEL based systems
by Alex Schultz 18 Feb '19

18 Feb '19

Ahoy Kolla folks, In TripleO/RDO we've been working towards getting python3 support ready when the next CentOS is released. We've been working towards getting the packaging all ready and have a basic setup working on fedora 28. We would like to get a head start in Kolla and I've proposed two possible solutions to support the python2/python3 transition in the container builds. I am looking for input from the Kolla folks on which of the two methods would be preferred so we can move forward. The first method is to handle the package names in the Dockerfiles themselves. https://review.openstack.org/#/c/632156/ (kolla python3 packages) https://review.openstack.org/#/c/624838/ (kolla WIP for fedora support (not expected to merge)) https://review.openstack.org/#/c/629679/ (tripleo specific overrides) IMHO think this method allows for a better transition between the python2 and python3 packages as it just keys off the distro_python3 setting that we added as part of https://review.openstack.org/#/c/631091/. It was mentioned that this might be more complex to follow and verbose due to the if/elses being added into the Docker files. I think the if/else complexity goes away once CentOS7 support is dropped so it's a minor transition (as I believe the target is Train for full python3 support). The second method is to add in a new configuration option that allows for package names to be overrideable/replaced. See https://review.openstack.org/#/c/636403/ (kolla package-replace option) https://review.openstack.org/#/c/636457/ (kolla python3 specifics) https://review.openstack.org/#/c/624838/ (kolla WIP for fedora support would need to be supplied to test) https://review.openstack.org/#/c/636472/ (tripleo specific overrides) IMHO I actually like the package-replace option for a few package overrides. I don't think this is a cleaner implementation for replacing all the packages because it becomes less obvious what packages would actually be used and it becomes more complex to manage. This one feels more like it's pushing the complexity to the end user and would still be problematic when CentOS8 comes out all the packages would still need to be replaced in all the Docker files (in the next cycle?). My personal preference would be to proceed with the first method and maybe merge the package-replace functionality if other would find it beneficial. I would be interested to hear if other think that the second option would be better in the long term. Thanks, -Alex

2 1

[tc][election] TC candidacy
by Thierry Carrez 18 Feb '19

18 Feb '19

Hi everyone, I've been on the OpenStack Technical Committee forever, and my original plan was to not run for re-election this cycle. Thanks to name recognition, incumbents have traditionally easily been reelected. Stepping down is the only way to make room for new leaders to emerge, a process that is necessary to keep alignment between the Technical Committee members and the active contributors that are their constituency. So, having room for new members to be elected is necessary. At the same time, there is value in historical perspective, and experienced members are useful to help newcomers into their role. We also need to be careful about the message that too many people stepping down would send. So, it's a mixed bag -- we need enough, but not too many people stepping down. Over the past cycles, we introduced about 3 new people at every election. I think renewing 3 or 4 people every 6 months in a committee of 13 members is the right balance. We already have three experienced members who announced they would not be running again this cycle, so I feel like it might not be the best moment for me to step down. With the OSF shifting from being solely about OpenStack to more generally tackling the open infrastructure space, my focus has certainly expanded lately. But I don't want to feed the trolls arguing that we are leaving OpenStack behind. I'm not done with the OpenStack TC yet, and would like to advance two more things before stepping down. OpenStack is in the middle of a transition -- from hyped project driven by startups and big service providers to a more stable project led by people running it or having a business depending on it. A lot of the systems and processes that I helped put in place to cope with explosive growth are now holding us back. We need to adapt them to a new era, and I feel like I can help bringing the original perspective of why those systems were put in place, so hopefully we do not end up throwing the baby with the bath water. I feel like there is also a lot of work to do to better present what we produce. The work on the OpenStack map and the "software" pages on the openstack.org website is far from complete. OpenStack is still much harder to navigate and understand for a newcomer than it should be. I want to continue that work for one more year. So I am announcing my candidacy for a position on the OpenStack Technical Committee in the upcoming election. Thank you for your consideration ! -- Thierry Carrez (ttx)

1 0

[tc][election] TC Candidacy
by Zane Bitter 17 Feb '19

17 Feb '19

Hello again friends, I'm running again for a second term on the Technical Committee. (For the record, I don't plan to seek a third term next year.) I've been part of the OpenStack community since 2012, and as well as a TC member I am also a core reviewer for Heat and (since very recently) Oslo. I think of the TC as effectively the 'core reviewer' team for a larger group of folks who participate in the governance of OpenStack (a group that I think we should be aiming to expand even further). I'm deeply grateful to the community for giving me the opportunity to work with what is a fantastic team of people. Here's what I've been up to in the past year on the TC: - I supported Julia's initiative to spread constructive code-review techniques by distilling some of our annual endless threads on code-review etiquette into a linkable page in the Project Teams Guide.[1] A number of people, in one case an entire team, told me that they'd tweaked their approach to code review after getting ideas from this document. (This feedback is *much* appreciated by the way, because from the TC perspective it can be very hard to tell the difference between achieving lazy consensus and shouting into the void.) - I wrote the draft of and edited contributions to what became the Vision for OpenStack Clouds,[2] contacted every affected team to explain what it meant for them individually, and presented it to the OSF Board in Berlin for their feedback as well. - I helped drive the definition of a process for determining which versions of Python3 should be tested in a release.[3] That should help us make the transitions smoothly in future, though it unfortunately started too late for Stein. - I've been actively engaged with members of the OSF Board on the topic of the process for adding new Open Infrastructure projects to the Foundation, by passing on feedback from foundation members and from the TC's own experience with evaluating project applications, and trying to publicise the board's position in the community.[4] It's hard to imagine being able to get any of those done without being a TC member. As I've written elsewhere,[5] because the TC is the only project-wide elected body, leading the community to all move in the same direction is something that cannot happen without the TC. I plan to continue trying to do that, and encouraging others to do the same. Thanks for your consideration. cheers, Zane. [1] https://docs.openstack.org/project-team-guide/review-the-openstack-way.html [2] https://governance.openstack.org/tc/reference/technical-vision.html [3] https://governance.openstack.org/tc/resolutions/20181024-python-update-proc… [4] https://www.zerobanana.com/archive/2018/06/14#osf-expansion [5] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001841.…

2 2

[tc][elections] TC candidacy
by Mohammed Naser 17 Feb '19

17 Feb '19

Hi everyone: First of all, thank you very much for giving me the opportunity to be part of the technical committee over the past term within the OpenStack project governance. I’ve also taken the vice chair role which I have had to serve for sometime during the time that our chair (Doug) was out of the office. In my candidacy email for my last term, there was a few things that I brought up which I think are still very important, as well as a few others which I think we’ve made great progress in. I’d like to start talking about those first. I still believe that it’s really important to have a contact with the users and deployers, something that we’re slowly getting better at. I have found that having some of those very large operators that sit in our technical committee meetings at the PTG super productive, because they bring an important perspective to the technical committee. As I help manage a public cloud and several private clouds all over the world, I’ve seen a lot of stories about OpenStack experiences, shortcomings and seeing how users consume OpenStack. It’s a very eye opening experience and it’s built up a strong basis to be able to formulate technical decisions and understanding the impact it has on all of our different users. I think this information is a really strong asset. I mentioned that we needed to work on improving our bridges with other communities such as Kubernetes. I’ve helped add and provide resources for OpenLab to help bring CI for the Kubernetes OpenStack cloud provider, worked on Magnum changes to help better integrate and test the project and even added resources which allowed Magnum to run full functional Kubernetes tests in it’s gate (with a work in progress of adding conformance tests). While the TC is about governance, I also think it’s important for us to get some work that gets the critical moving pieces running done. I’ve also worked with a few teams in order to help and somehow mediate a discussion to facilitate the split of the placement service and provided operator feedback, participated in the split meetings and helped to push things in the direction to make it happen. However, learning a few lessons in the way about how we might go about doing something like this in the future. I’ve also increased my engagement with our APAC community by speaking more often with them over WeChat. There is a tremendous amount of knowledge and wonderful community of people who want to participate. I’ve tried my best to also build a ‘bridge’ by sharing things that might make sense for them to see from our mailing lists (for example, the most recent one about our upcoming release name). For the upcoming term, I think that we should work on increasing our engagement with other communities. In addition, providing guidance and leadership for groups and projects that need help to merge their features, even if it involves finding the right person and asking them for a review. I’d like to personally have a more “hands-on” approach and try to work more closely with the teams, help shape and provide input into the direction of their project (while looking at the overall picture). I’d also like us to try and be more engaged with the other OSF projects such as Kata containers, StarlingX, Airship and Zuul. While the last one is our darling that was created out of our use, I think providing a bridge with the others would provide a lot of value as well. Thank you for giving me the opportunity to serve as part of your technical committee, I hope to be able to continue to help over the next term. Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 3

[Heat] Reg accessing variables of resource group heat api
by NANTHINI A A 17 Feb '19

17 Feb '19

Hi , We are developing heat templates for our vnf deployment .It includes multiple resources .We want to repeat the resource and hence used the api RESOURCE GROUP . Attached are the templates which we used Set1.yaml -> has the resources we want to repeat Setrepeat.yaml -> has the resource group api with count . We want to access the variables of resource in set1.yaml while repeating it with count .Eg . port name ,port fixed ip address we want to change in each set . Please let us know how we can have a variable with each repeated resource . Thanks, A.Nanthini

4 11

[all][TC] 'Train' Technical Committee Nominations Open
by Kendall Nelson 17 Feb '19

17 Feb '19

Hello All, Nominations for the Technical Committee positions (7 positions) are now open and will remain open until Feb 19, 2019 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained on the election website[1]. Please note that the name of the file should match an email address in the foundation member profile of the candidate. Also for TC candidates election officials refer to the community member profiles at [2] please take this opportunity to ensure that your profile contains current information. Candidates for the Technical Committee Positions: Any Foundation individual member can propose their candidacy for an available, directly-elected TC seat. The election will be held from Feb 26, 2019 23:45 UTC through to Mar 05, 2019 23:45 UTC. The electorate are the Foundation individual members that are also committers for one of the official teams[3] over the Feb 09, 2018 00:00 UTC - Feb 19, 2019 00:00 UTC timeframe (Rocky to Stein), as well as the extra-ATCs who are acknowledged by the TC[4]. Please see the website[5] for additional details about this election. Please find below the timeline: TC nomination starts @ Feb 12, 2019 23:45 UTC TC nomination ends @ Feb 19, 2019 23:45 UTC TC campaigning starts @ Feb 19, 2019 23:45 UTC TC campaigning ends @ Feb 26, 2019 23:45 UTC TC elections starts @ Feb 26, 2019 23:45 UTC TC elections ends @ Mar 05, 2019 23:45 UTC If you have any questions please be sure to either ask them on the mailing list or to the elections officials[6]. Thank you, -Kendall Nelson (diablo_rojo) [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy [2] http://www.openstack.org/community/members/ [3] https://governance.openstack.org/tc/reference/projects/ [4] https://releases.openstack.org/stein/schedule.html#p-extra-atcs [5] https://governance.openstack.org/election/ [6] http://governance.openstack.org/election/#election-officials

2 1

[User-committee] UC Candidacy
by Belmiro Moreira 17 Feb '19

17 Feb '19

Greetings, I'd like to announce my candidacy for the OpenStack User Committee (UC). I'm involved with OpenStack since 2011 when CERN started to investigate a Cloud Infrastructure solution. I work in the design/deployment/operation of the CERN OpenStack Cloud (from 0 to +300k cores). My particular interest has been how to scale and operate large OpenStack deployments. I was an active member of the Large Deployment Team (LDT), a group of operators that shared ideas on how to scale OpenStack. I had the privilege to learn from a talented group of Operators on how they manage/run their infrastructures. I'm fortunate enough to have attended all OpenStack Summits since San Francisco (2012). I'm a regular speaker talking about my experience operating OpenStack at scale. Also, I serve regularly as a track chair, participated in few OpenStack Days, Ops Meetups and wrote several blog posts. I believe that the Operators/User community should have an active role in the design of the next features for the OpenStack/Open Infrastructure projects. If elected I will focus to engage the Operator/Users community with the different Development teams. It would be an honor to be an advocate of this great community and promote its mission. Thank you for your consideration, Belmiro Moreira

2 1

[all][tc] Formalizing cross-project pop-up teams
by Thierry Carrez 16 Feb '19

16 Feb '19

TL;DR: Maybe to help with cross-project work we should formalize temporary teams with clear objective and disband criteria, under the model of Kubernetes "working groups". Long version: Work in OpenStack is organized around project teams, who each own a set of git repositories. One well-known drawback of this organization is that it makes cross-project work harder, as someone has to coordinate activities that ultimately affects multiple project teams. We tried various ways to facilitate cross-project work in the past. It started with a top-level repository of cross-project specs, a formal effort which failed due to a disconnect between the spec approvers (TC), the people signed up to push the work, and the teams that would need to approve the independent work items. This was replaced by more informal "champions", doing project-management and other heavy lifting to get things done cross-project. This proved successful, but champions are often facing an up-hill battle and often suffer from lack of visibility / blessing / validation. SIGs are another construct that helps holding discussions and coordinating work around OpenStack problem spaces, beyond specific project teams. Those are great as a permanent structure, but sometimes struggle to translate into specific development work, and are a bit heavy-weight just to coordinate a given set of work items. Community goals fill the gap between champions and SIGs by blessing a given set of cross-community goals for a given release. However, given their nature (being blessed by the TC at every cycle), they are a better fit for small, cycle-long objectives that affect most of the OpenStack project teams, and great to push consistency across all projects. It feels like we are missing a way to formally describe a short-term, cross-project objective that only affects a number of teams, is not tied to a specific cycle, and organize work around a temporary team specifically formed to reach that objective. A team that would get support from the various affected project teams, increasing chances of success. Kubernetes encountered the same problem, with work organized around owners and permanent SIGs. They created the concept of a "working group"[1] with a clear limited objective, and a clear disband criteria. I feel like adopting something like it in OpenStack could help with work that affects multiple projects. We would not name it "working group" since that's already overloaded in OpenStack, but maybe "pop-up team" to stress the temporary nature of it. We've been sort-of informally using those in the past, but maybe formalizing and listing them could help getting extra visibility and prioritization. Thoughts? Alternate solutions? [1] https://github.com/kubernetes/community/blob/master/committee-steering/gove… -- Thierry Carrez (ttx)

11 23

[Tacker][Searchlight] Implementing Tacker plugin for Searchlight
by Trinh Nguyen 15 Feb '19

15 Feb '19

Hi Tacker team, The Searchlight team is trying to implement a Tacker plugin for Searchlight that has two features: - Index Tacker resource info & events into ElasticSearch - Create an event trigger engine to provide self-healing if needed There's nothing needed to be changed at the Tacker side but it would be great if you guys can help to suggest what resource info we should get and where we can get those. The proposed spec of the feature is here [1]. My initial plan is to use the tacker client to list the resources and the oslo_messeging bus to get the events/notifications. [1] https://review.openstack.org/#/c/636856/ Any concerns or questions let me know. Many thanks, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[dev][keystone] Launchpad blueprint reckoning
by Lance Bragstad 15 Feb '19

15 Feb '19

Over the last couple of years, our launchpad blueprints have grown unruly [0] (~77 blueprints a few days ago). The majority of them were in "New" status, unmaintained, and several years old (some dating back to 2013). Even though we've been using specifications [1] for several years, people still get confused when they see conflicting or inaccurate blueprints. After another person tripped over a duplicate blueprint this week, cmurphy, vishakha, and I decided to devote some attention to it. We tracked the work in an etherpad [2] - so we can still find links to things. First, if you are the owner of a blueprint that was marked as "Obsolete", you should see a comment on the whiteboard that includes a reason or justification. If you'd like to continue the discussion about your feature request, please open a specification against the openstack/keystone-specs repository instead. For historical context, when we converted to specifications, we were only supposed to create blueprints for tracking the work after the specification was merged. Unfortunately, I don't think this process was ever written down, which I'm sure attributed to blueprint bloat over the years. Second, if you track work regularly using blueprints or plan on delivering something for Stein, please make sure your blueprint in Launchpad is approved and tracked to the appropriate release (this should already be done, but feel free to double check). The team doesn't plan on switching processes for feature tracking mid-release. Instead, we're going to continue tracking feature work with launchpad blueprints for the remainder of Stein. Currently, the team is leaning heavily towards using RFE bug reports for new feature work, which we can easily switch to in Train. The main reason for this switch is that bug comments are immutable with better timestamps while blueprint whiteboards are editable to anyone and not timestamped very well. We already have tooling in place to update bug reports based on commit messages and that will continue to work for RFE bug reports. Third, any existing blueprints that aren't targeted for Stein but are good ideas, should be converted to RFE bug reports. All context from the blueprint will need to be ported to the bug report. After a sufficient RFE bug report is opened, the blueprint should be marked as "Superseded" or "Obsolete" *with* a link to the newly opened bug. While this is tedious, there aren't nearly as many blueprints open now as there were a couple of days ago. If you're interested in assisting with this effort, let me know. Fourth, after moving non-Stein blueprints to RFE bugs, only Stein related blueprints should be open in launchpad. Once Stein is released, we'll go ahead disable keystone blueprints. Finally, we need to overhaul a portion of our contributor guide to include information around this process. The goal should be to make that documentation clear enough that we don't have this issue again. I plan on getting something up for review soon, but I don't have anything currently, so if someone is interested in taking a shot at writing this document, please feel free to do so. Morgan has a patch up to replace blueprint usage with RFE bugs in the specification template [3]. We can air out any comments, questions, or concerns here in the thread. Thanks, Lance [0] https://blueprints.launchpad.net/keystone [1] http://specs.openstack.org/openstack/keystone-specs/ [2] https://etherpad.openstack.org/p/keystone-blueprint-cleanup [3] https://review.openstack.org/#/c/625282/

3 8