- openstack-discuss - lists.openstack.org

[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 06 Mar '19

06 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 06 Mar '19

06 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 06 Mar '19

06 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 06 Mar '19

06 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 06 Mar '19

06 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 06 Mar '19

06 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 06 Mar '19

06 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

[ptl][swift][election] Tim Burke's candidacy for Swift PTL
by Tim Burke 06 Mar '19

06 Mar '19

I'd like to announce my candidacy for Swift PTL. Within the Swift community, we have established traditions that ensure we move carefully, and with purpose. Somewhere out there, there is an out-of-date-node with data scribbled down in a legacy format that we must still make durable, or an old client written against a years-old version of Swift that continues to perform its business-critical function. By keeping these realities in mind, we have (out of necessity) featured rolling-upgrades since our first release. This is not to say that we must therefore move slowly (though we often do, particularly now that the hype wave has crested, crashed, and begun to ebb). Despite our conservatism, there are few signs of ossification: new use-cases and new workloads bring new demands, and Swift evolves to satisfy them with new features. We now approach a new transition: John, our long-serving PTL, is stepping down. I have no worries, however; the Swift community is accustomed to dealing with (and thinking in terms of) an array of mostly-independent actors, working to improve the state of the system. The Swift developers are among the best I've had the pleasure to work alongside, and I have no doubt that Swift will continue to improve. I believe the best way I can further that improvement is to serve as PTL; to listen to users; to engage with operators; to enable developers. We are working on great, ambitious projects: * Pete from Red Hat is driving us supporting Python 3. We've known for a while that this would be necessary; it's good to see it finally happening. * Alex and Romain from OVH are upstreaming their (already running in production!) alternate diskfile format to support small objects. * Clay at SwiftStack continues to make replication and reconstruction better. * Kazuhiro at NTT is reworking the object-expirer queue, turning it into a general task queue. There is a lot going on in Swift. I can't wait to see what we build. Tim Burke

1 0

Re: [scientific-sig] IRC meeting 1100 UTC: Edge computing and Scientific use cases
by Bogdan Dobrelya 06 Mar '19

06 Mar '19

[added edge-computing(a)lists.openstack.org] JFYI: some background for ICFC 2019 event: > ================================================================================= > IEEE International Conference on Fog Computing (ICFC 2019) > June 24-26, 2019 > Prague, Czech Republic > http://conferences.computer.org/ICFC/2019/ > Co-located with the IEEE International Conference on Cloud Engineering > (IC2E 2019) > ================================================================================== > > Important Dates > > -------------------- > > Paper registration and abstract: Nov 1st, 2018 > Full paper submission due: Nov 8th, 2018 > Notification of paper acceptance: Jan. 20th, 2019 > Workshop and tutorial proposals due: Nov 11, 2018 > Notification of proposal acceptance: Nov 18, 2018 So I have a draft of a positioning paper [0]... what missed that event :) tl;dr: It is known that causal consistency is the best suitable for high-latency, high-scale and highly dynamic nature of membership in clusters... which is exactly what multiple autonomous control planes represent in edge clouds for post-MVP phases. Even though the paper didn't make it for ICFC 2019 acceptance as I naively planned (not), hopefully we as community could find some use of it in future. Like collaboratively improving its contents, or making it readable by humans, then pushing it for other places for wider audience. It's just free for any use, please go for it! :) Or maybe we could prototyping something for OpenStack edge post-MVP cases out of SwiftCloud [1] just like the folks did for CockroachDB [2]? Note, while that github repo does not look super alive and driven by many contributions, that work looks really promising, you can read more for the theoretical fundamentals of it in "SwiftCloud: Fault-Tolerant Geo-Replication Integrated all the Way to the Client Machine" and "SwiftCloud: Write fast, read in the past: Causal consistency for client-side applications". That really buys to me to put it all client-sided at the edge and make it doing all geo-replication dances. Ofc there is more for prototyping. For example, building some Bolt-on'ish shim middleware on top of any popular eventual consistent storage, like Riak (not sure there is opensource implementations for Bolt-on yet). Or trying something at api-to-api level for high-level synchronization with "delayed replication" of queued operations. PS. @Pierre and @Adrien I gave it a quick glimpse into some of the sources you linked for the related work section of the positioning paper, thank you a lot for that and x1000 for authoring such things. So the draft now almost hits the recommended limit of a 6 pages, so I think there should be pretty much it for a positioning paper. [0] https://github.com/bogdando/papers-ieee/blob/master/ICFC-2019/LaTeX/positio… [1] https://github.com/SyncFree/SwiftCloud [2] http://beyondtheclouds.github.io/blog/openstack/cockroachdb/2018/06/04/eval… On 27.02.2019 14:33, Adrien Lebre wrote: > Hi, > > Getting a look to this post could also make sense: > http://beyondtheclouds.github.io/blog/openstack/cockroachdb/2018/06/04/eval… > > Best regards, > Adrien > PS: Thanks Pierre. > -- > Prof. IMT Atlantique / Inria / LS2N > Head of the STACK Research Group > www.emn.fr/x-info/alebre08 <http://www.emn.fr/x-info/alebre08> > >> On 27 Feb 2019, at 14:18, Pierre Riteau <pierre(a)stackhpc.com >> <mailto:pierre@stackhpc.com>> wrote: >> >> Hello Bogdan, >> >> In the context of data management in edge computing, you may be >> interested by research done by the Discovery Initiative: >> http://beyondtheclouds.github.io/publications.html >> I am adding Adrien Lèbre to the thread, he may be able to point you to >> the publications most relevant to your whitepaper draft. >> >> Best wishes, >> Pierre Riteau >> >> On Wed, 27 Feb 2019 at 10:21, Bogdan Dobrelya <bdobreli(a)redhat.com> wrote: >>> >>> On 27.02.2019 10:51, Stig Telfer wrote: >>>> Hi All - >>>> >>>> We have an IRC meeting at 1100 UTC (about an hour’s time) in channel >>>> #openstack-meeting. Everyone is welcome. >>>> >>>> Today’s agenda is here: >>>> >>>> https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_February_27th_20… >>>> >>>> Today’s main event is that we have Ildikó Vancsa joining us to talk >>>> about edge computing use cases and find overlap with Scientific SIG >>>> use cases. >>>> >>>> Cheers, >>>> Stig >>>> >>>> >>> >>> Edge computing is a *great* topic for lot of future research work indeed. >>> Thank you for this useful announcement, appreciated! >>> I'll attend at least the first half of it, and in case I'll miss the >>> agenda item that I placed at the end of the list, please be kind to >>> review that research request with my absence as well. Thanks! >>> >>> >>> -- >>> Best regards, >>> Bogdan Dobrelya, >>> Irc #bogdando >>> > -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 1