- openstack-discuss - lists.openstack.org

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

[nova][qa] Should we make legacy-grenade-dsvm-neutron-multinode-live-migration voting?
by Matt Riedemann 06 Mar '19

06 Mar '19

The legacy-grenade-dsvm-neutron-multinode-live-migration job was recently fixed [1][2] but had been broken for awhile because it's non-voting so no one really noticed. The unique thing about this job is it runs live migration tests in a grenade setting where one of the computes is n-1 and it does the live migration back and forth between the nodes so we have old->new and new->old coverage, and it does this across local disk and shared storage with ceph. Now that it's working again, should we make it voting? It came up while discussing regression test coverage for Artom's NUMA live migration series. It seems like a no-brainer to me at least that we should be gating on this. Before doing that, I'd like to move the job config from openstack-zuul-jobs to nova so we "own" any changes to the job and then might also consider converting it to zuul v3, but that's not a blocker to make it voting. [1] https://review.openstack.org/#/c/634962/ [2] https://review.openstack.org/#/c/637231/ -- Thanks, Matt

5 5

Adding overcloud server entries to /etc/hosts on undercloud
by James LaBarre 06 Mar '19

06 Mar '19

I have been doing this manually at present, but I had wondered if there is a switch/setting for the overcloud deploy to add the overcloud servers to the /etc/hosts file as part of the deploy?

2 2

[tc] Train Technical Committee kickoff
by Doug Hellmann 06 Mar '19

06 Mar '19

Now that the most recent TC election results are in [1], it is time to start organizing the committee for the Train cycle [2]. First, thank you to all of our election officials for helping us to run a smooth and transparent election process, yet again. I have been involved with other communities where elections were fraught and tense operations. You all make it look easy. I would also like to thank our outgoing members, Chris Dent (cdnet), Davanum Srinivas (dims), and Sean McGinnis (smcginnis) for their service as they rotate off of the committee. Each of them has worked on the TC for several years, and in community leadership roles before then. They are excellent examples of open source leaders. And of course, welcome to our new members: Alexandra Settle (asettle), Jim Rollenhagen (jroll), and Rico Lin (ricolin). We're excited to have you join the team! The next step for us is to approve the patch prepared by the election officials to update the TC roster. Please take a few minutes to vote on https://review.openstack.org/#/c/641171/ now. After the TC is seated, we need to select a chair. As I announced at our February meeting, based on some other commitments that I have I think it is best if I not serve as chair this term. If you are interested in being chair, please propose a patch on top of the election patch to add the '{chair}' designation next to your name. As a TC member, we have two primary ways of communicating. Please take a moment to ensure that your email filters are configured to ensure you see any messages on the mailing list with the '[tc]' topic tag. Please also join the '#openstack-tc' channel on IRC, and set a notification for the string 'tc-members'. Thank you, and I look forward to continuing to work with all of you this cycle. -- Doug [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003503.ht… [2] http://git.openstack.org/cgit/openstack/governance/tree/CHAIR.rst#n67

1 2