March 2019 - openstack-discuss - lists.openstack.org

[ptl][freezer][election] It's time to add your candidacy for Freezer PTL
by Trinh Nguyen 07 Mar '19

07 Mar '19

Hi team, This week (5-12 Mar.) is for you to add your candidacy for Freezer PTL. Please follow this guide [1] to do that, (e.g, [2]). Bests, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] https://review.openstack.org/#/c/641193/ -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[ptl] [Cyborg] [election] Sundar Nadathur's candidacy for Cyborg PTL
by Nadathur, Sundar 07 Mar '19

07 Mar '19

Hello Stackers, I'd like to announce my candidacy for PTL role of Cyborg for the Train cycle. Cyborg got to a rolling start in 2018 led by Howard (Zhipeng) Huang. Under his leadership, we established the basic infrastructure for sustained growth, resulting in our official release in Rocky. During the Stein release, with Li Liu as the PTL, we have made substantial progress, particularly in defining a clean database schema and device model that will form the basis for future work. In both cycles, we had several illuminating discussions with Nova developers to define how Cyborg would interact with Nova. As we move forward, there is considerable potential in Cyborg, as evidenced by the interest shown by cloud/telco operators around the world. To realize this potential and deliver real-world use cases, here's what we'll aim to accomplish in the Train cycle: * Complete the integration with Nova, so that we can launch VMs with accelerators attached to them. * Enable consumption of accelerators either as raw devices or as offloaded functions. * Support a variety of devices, by enabling Cyborg drivers for them. * Lay the groundwork for features, such as performance monitoring and health monitoring, to enable usage in production. Thanks. Best Regards, Sundar Nadathur

3 2

[Cyborg] PTL Non-Candidacy
by Li Liu 07 Mar '19

07 Mar '19

Hi team, The PTL self-nomination is starting this week[0]. I want to announce that I will not be running for Cyborg PTL for next term. It's been a great pleasure to work as a PTL with you guys and I will continue being around as core contributor for the foreseeable future. [0] https://releases.openstack.org/stein/schedule.html#t-ptl-nominations -- Thank you Regards Li Liu

2 1

[oslo][ptl][election] PTL Candidacy
by Ben Nemec 07 Mar '19

07 Mar '19

I'm not putting my name in the subject because Oslo is all about reducing duplication and I'm quite certain every reasonable mail client already displays my name near the subject anyway. :-P Anyway, here's what I submitted to the election repo[0]: """ I am running for Oslo PTL in the Train cycle. I have been Oslo PTL for around a year now, and in that time we've been able to address a number of longstanding user requests, such as the removal of plaintext secrets from config files and a validator for config files. However, that doesn't mean our job is done. Here are some things I want to focus on for the next cycle: * Mentor new contributors. In the past cycle we had a number of our most experienced contributors pulled away to other projects, either in part or in total. The good news is we have some newer contributors who I believe can step in to fill those gaps. We need to make sure to help them along as much as possible. * Support cycle goals. In Stein we were able to add an Oslo library to make the goal implementation easier for all of the other OpenStack projects. We should continue to look for such opportunities with the new cycle goals for Train. * Storyboard migration. We've been discussing this pretty much since I became PTL, and I know some progress was made in Stein toward addressing some of my concerns with this. I think this is likely to be the cycle where we can go ahead with the move. * oslo.limit. I still very much want this to be a thing and will do whatever I can to help make it happen. I think that's it for now, but as always I am open to suggestions on things Oslo can do to make everyone's life easier. """ Thanks. -Ben 0: https://review.openstack.org/#/c/641503/

1 0

[neutron][devstack] Using git source for networking devstack based jobs
by Boden Russell 07 Mar '19

07 Mar '19

If your networking project uses required projects (aka "Siblings") [1], please read on. It's recently come to our attention [2][3][4] that some required networking projects are not being pulled from git source in devstack based jobs. As a result, a number of networking gate jobs were impacted [3]. While we have a short term fix in place, it doesn't solve the issue longer term. Today it's still not clear why some dependencies are coming from source and others aren't [2]. However, before digging deeper, we should probably step back and ensure we are heading down the right path. The question is; do we want these devstack jobs using their dependencies from git source, or should they be using tagged branches/releases of them instead?? Using git source seems to increase development velocity; not having to wait/coordinate on a tagged dependency, but at the same time it's also a moving target. My personal vote is to use git source; it will help maintain the velocity of neutron-lib and other cross-project efforts. It would be helpful to get some feedback from the other networking teams on what approach they think would work best. Thanks [1] https://docs.openstack.org/infra/manual/zuulv3.html#installation-of-sibling… [2] https://bugs.launchpad.net/devstack/+bug/1817555 [3] https://bugs.launchpad.net/tricircle/+bug/1816644 [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003010…

3 6

Openstack network queries
by dhanesh1212121212 07 Mar '19

07 Mar '19

Hi Please help me understand openstack networking. My understanding: - We have three type of virtual network in neutron. 1.flat 2. Vlan 3. Vxlan/gre Based on the above type wat are the different ways we can create private and public network. Private network only for internal ip of instance. Public network will create submit and use as floating ip. We can either assign public up network from network provider or can use ip address which has internet. Please give example for each case. Regards, Dhan.

2 1

[openstack-helm] Team Meeting (12th March 2019)
by Pete Birley 07 Mar '19

07 Mar '19

Hey! The next OpenStack-Helm meeting will be held on the 12th March, at 3pm UTC in #openstack-meeting-4 in freenode IRC. Thanks to all those who could attend the one we held on the 5th March: * the agenda we used is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-03-05 * the minutes logged here: http://eavesdrop.openstack.org/meetings/openstack_helm/2019/openstack_helm.… It would be great if people interested in OSH could attend, though we appreciate that's not possible, or desirable, for many. The agenda for the next meeting is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-03-12 please feel free to add to it, even if you cannot attend. Look forward to seeing you all either in IRC or here. Cheers Pete

1 0

[goals][upgrade-checkers] Week R-5 Update
by Matt Riedemann 07 Mar '19

07 Mar '19

We are less than 24 hours from feature freeze for Stein. Compared to the last update for R-9 [1] nothing has really changed as far as open reviews [2]. cloudkitty, aodh and ceilometer still have changes ready to go for the base framework (the cloudkitty one does an actual check, not a placeholder). There is also a +2 on the horizon change [3]. I don't know if that is too high risk at this point to merge or not. At this point I'm happy to just say the goal is complete since the vast majority of service projects in OpenStack at least implemented the base framework patch so they can start adding real upgrade checks. For the other projects that don't yet, if they are just adding the framework anyway, they could do that in Train. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002541… [2] https://review.openstack.org/#/q/topic:upgrade-checkers+status:open [3] https://review.openstack.org/#/c/631785/ -- Thanks, Matt

2 1

[keystone] Summarizing Stein RBAC work
by Lance Bragstad 07 Mar '19

07 Mar '19

Yesterday, in the keystone meeting [0], we talked about what we want to do with the remaining scope and default roles work in keystone. With all the patches proposed, merged, and reviewed around this work, I thought a summary might be beneficial for everyone. Besides, despite my best efforts I still don't share the same polarity with buses. So, getting this information out is probably best for everyone, including other developers looking to do something similar in their services. For context, we landed a major refactor in Rocky allowing keystone to consume different scopes (e.g., project, domain, and system), making the entire keystone API more self-serviceable. We also decided to implement default roles since we already planned on making policy changes, which gives us things like read-only support out-of-the-box. Right around the time Stein opened for development, I took an initial pass at opening bugs to track this work. Turns out refactoring the authorization of an entire API is a significant amount of work, especially to track in a single bug report [1]. We kept new bug reports specific to one resource at a time. If the API made sense to expose with multiple scopes (e.g., allowing project users, domain users, and system users to all access the API) we opened a bug, specifically to implement those scopes. We tagged these bugs with the `system-scope` tag in Launchpad [2]. Resources in keystone that needed to implement support for default roles required separate bug reports. We tagged these bugs with the `default-roles` tag in Launchpad [3]. All bugs that fell into these two camps also received the `policy` tag. Altogether, we broke the work to implement scope types and default roles across keystone's API into 39 different bug reports [4]. Of those 39 bug reports, 13 are for correcting scope behavior, which exposes more functionality to end users, safely. The remaining 26 are for implementing default roles, which gives us things like read-only support. Of the 13 scope bugs we: - fixed 2 - have 7 in progress - have 4 awaiting fixes Note that some of the fixes above are dependent on a devstack patch to correct what tempest assumes about certain scopes [5]. Of the 26 bugs for default roles we: - fixed 14 - have 12 awaiting fixes In total, of the 39 bugs we opened for the entirety of this work in Stein we: - fixed 16 (~41%) - have 7 in progress (~17%) - have 16 awaiting fixes (~41%) I took one final pass through all of keystone's policies yesterday to make sure we have everything captured in bug reports. If you see something that I missed, let me know or open a bug report so that we can capture the information. To highlight the work required to get us this far, as of e8d9791c6ecea1bf5fd4878b57c892b0a4c8a19e, we've merged [6] 259 tests [7]. These tests are reused to execute 593 functional protection tests [8] that exercise the default roles against various scopes and ensures users can do what we expect. These number don't include the patches that are still in review [9] that implement more protection testing. I think it's safe to say that we're not going to get the remaining work merged into Stein. However, are there specific resources we want to prioritize for Stein of the remaining bug reports [10]? Thanks, Lance [0] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-03-05-1… [1] https://bugs.launchpad.net/keystone/+bug/968696 [2] http://tinyurl.com/y3ux97ma [3] http://tinyurl.com/y3y779e8 [4] http://tinyurl.com/y649w43n [5] https://review.openstack.org/#/c/624794/ [6] https://review.openstack.org/#/q/status:merged+project:openstack/keystone+b… [7] grep -R 'def test_' keystone/tests/unit/protection/ | wc -l [8] tox -e py37 -- keystone.tests.unit.protection [9] https://review.openstack.org/#/q/status:open+project:openstack/keystone+bra… [10] http://tinyurl.com/y4vwdsjz

1 0

[sahara][elections] Jeremy Freudberg's candidacy for Sahara PTL
by Jeremy Freudberg 07 Mar '19

07 Mar '19

Hello all! This is an official announcement of my candidacy for PTL of Sahara for the Train development cycle. # Who I am My first introduction to Sahara was in the summer of 2016, as an operator. It wasn't long until I sent my first patch upstream. Following the first PTG in Atlanta in 2017 I became increasingly involved with the project and later that year I became a core reviewer for Sahara. I must emphasize that all of this was set off by a series of fortunate coincidences; regardless, it's still a nice story of OpenStack gaining a new (and lasting) contributor. My affiliations remain with Red Hat and the Massachusetts Open Cloud (both of which have at various times funded my work on Sahara). Like many 22-year-olds, I'm about to finish undergrad: I studied computer science and linguistics. # Goals for Train I am impressed with what we have accomplished in past cycles with such a small team. We've implemented big features (APIv2, out-of-tree plugins) and kept up with the pace of OpenStack as a whole. Looking at where we stand now I propose that we focus on the following areas during the Train cycle: * Castellan/Barbican integration: it's been broken for an embarrassing amount of time, yet it's a highly desirable feature. * Python support for Spark EDP jobs: many users come to Sahara expecting this but then leave disappointed... it's time to bite the bullet. * Finishing transition to sahara-image-pack: let's have support for all our plugins in a single tool, so that sahara-image-elements can be deprecated. * Rehoming sahara-extra: the code should be hosted in one place, and I believe that place should be Apache's repository, where it will receive proper care. I have chosen these goals as a strategic investment into the reduction of future maintainers' pain. The emphasis is on fixing existing features and cutting down the number of components to maintain. Any extra capacity should be directed towards plugin upgrades or towards increasing the breadth of scenarios tested in upstream CI. # Beyond Train It is hard to tell what the future will hold. The team is at its all-time smallest. I'd suggest that the focus on stability continues. # Acknowledgements We owe a massive debt of gratitude to Telles Nobrega, who heroically served as Sahara PTL for four exhausting-yet-rewarding cycles. I also want to thank all those who have ever contributed to Sahara (or to Savanna, or, for the trivia nerds, EHO). We wouldn't be here without you. # Conclusion I'm continously honored to be a part of the OpenStack community and of the Sahara team. Thanks for your consideration. Here's to a great cycle. Best, Jeremy

1 0