- openstack-discuss - lists.openstack.org

[infra] OpenDev feedback forum session summary
by Jeremy Stanley 10 Dec '18

10 Dec '18

Wednesday afternoon at the OpenStack Summit we met to discuss the plan for the upcoming transition of the OpenStack Infrastructure team to an independent effort named OpenDev. Notes were recorded at https://etherpad.openstack.org/p/BER-opendev-feedback-and-missing-features and form the basis of the summary with follows. For those unfamiliar with this topic, the announcement at http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html provides some background and context. Much of what follows may be a reiteration of things also covered there, so please excuse any redundancy on my part. To start out, we (re)announced that we have chosen a name (OpenDev) and a domain (opendev.org) so can more effectively plan for DNS changes for most of the services we currently host under the "legacy" (for us) openstack.org domain. It was also pointed out that while we expect to maintain convenience redirects and aliases from old hostnames for all services we reasonably can so as to minimize disruption, there will still be some unavoidable discontinuities for users from time to time as we work through this. We talked for a bit about options for decentralizing GitHub repository mirroring so that the current team no longer needs to maintain it, and how to put it in control of people who want to manage those organizations there for themselves instead. Doing this with a job in Zuul's post pipeline (using encrypted secrets for authentication) was suggested as one possible means to avoid users all maintaining their own separate automation to accomplish the same thing. Interest in bare metal CI nodes in nodepool was brought up again. To reiterate, there's not really any technical reason we can't use them, more that prior offers to donate access to Nova/Ironic-managed nodes for this purpose never panned out. If you work for an organization which maintains a "bare metal cloud" we could reach over the open Internet and you'd consider carving out some of your capacity for our CI system, please do get in touch with us! We spent a bit of time covering user concerns about the transition to OpenDev and what reassurances we ought to provide. For starters, our regular contributors and root systems administrators will continue to be just as reachable and responsive as ever via IRC and mailing lists, even if the names of the channels and MLs may change as part of this transition. Similarly, our operations will remain as open and transparent as they are today... really nothing about how we maintain our systems is changing substantively as a part of the OpenDev effort, though certainly the ways in which we maintain our systems do still change and evolve over time as we seek to improve them so that will of course continue to be the case. Paul Belanger raised concerns that announcing OpenDev could result in a flood of new requests to host more projects. Well, really, I think that's what we hope for. I (apparently) pointed out that even when StackForge was first created back at the beginning of 2012, there wasn't much restriction as to what we would be willing to host. As interest in OpenDev spreads to new audiences, interest in participating in its maintenance and development should too grow. That said, we acknowledge that there are some scalability bottlenecks and manual/human steps in certain aspects of new project onboarding for now, so should be very up-front with any new projects about that fact. We're also not planning for any big marketing push to seek out additional projects at this point, but are happy to talk to any who discover us and are interested in the services we offer. Next, Paul Belanger brought up the possibility of "bring your own cloud" options for projects providing CI resources themselves. While we expect nodepool to have support for tenant-specific resources in the not-too-distant future, Jim Blair and Clark Boylan agreed the large pool of generic resources we operate with now is really where we see a lot of benefit and ability to drive efficiencies of scale. Then Monty Taylor talked for a while, according to the notes in the pad, and said things about earmarked resources potentially requiring a sort of "commons tax" or... something. Jim Rollenhagen asked whether we would potentially start to test and gate projects on GitHub too rather than just our Gerrit. Clark Boylan and Jim Blair noted that the current situation where we're testing pull requests for Kata's repositories is a bit of an experiment in that direction today and the challenges we've faced suggest that, while we'll likely continue to act as a third-party CI system for some projects hosted on GitHub (we're doing that with Ansible for example), we've discovered that trying to enforce gating in code review platforms we don't also control is not likely something we'll want to continue in the long term. It came up that our earlier ideas for flattening our Git namespace to reduce confusion and minimize future repository renames is now not looking as attractive. Instead we're probably going to need to embrace an explosion of new namespaces and find better ways to cope with the pain of renames in Gerrit as projects want to move between them over time. We're planning to only run one Gerrit for simplicity, so artificially creating "tenants" in it through prefixes in repository names is really the simplest solution we have to avoid different projects stepping on one another's toes with their name choices. Then we got into some policy discussions about namespace creation. Jim Blair talked about the potential to map Git/Gerrit repository namespaces to distinct Zuul tenants, and someone (might have been me? I was fairly jet-lagged and so don't really remember) asked about who decides what the requirements are for projects to create repositories in a particular namespace. In the case of OpenStack, the answer is almost certainly the OpenStack Technical Committee or at least some group to whom they delegate that responsibility. The OpenStack TC needs to discuss fairly early what its policies are for the "openstack" namespace (whether existing unofficial projects will be allowed to remain, whether addition of new unofficial projects will be allowed there) as well as whether it wants to allow creation of multiple separate namespaces for official OpenStack projects. The suggestion of nested "deep" namespaces like openstack/nova/nova came up at this point too. We also resolved that we need to look back into the project rename plugin for Gerrit. The last time we evaluated it, there wasn't much there. We've heard it's improved with newer Gerrit releases, but if it's still lacking we might want to contribute to making it more effective so we can handle the inevitable renames more easily in the future. And finally, as happens with most forum sessions, we stopped abruptly because we ran over and it was Kendall Nelson's turn to start getting ops feedback for the Contributor Guide. ;) -- Jeremy Stanley

2 1

[loci] How to add some agent to loci images
by SIRI KIM 10 Dec '18

10 Dec '18

Hello, Jean. I tried to add lbaas-agent and fwaas-agent to official loci neutron image. To pass openstack-helm gate test, I need lbaas-agent and fwaas-agent. I found your openstack source repository is repository: 172.17.0.1:5000/loci/requirements Please let me know I can I add lbaas-agent and fwaas-agent to official loci neutron image. Thanks, Siri

4 4

[nova][dev] Stein blueprint tracking status
by melanie witt 10 Dec '18

10 Dec '18

Hey all, Similar to previous cycles, I've created an etherpad for tracking status of Approved blueprints for Stein: https://etherpad.openstack.org/p/nova-stein-blueprint-status Please feel free to use it to help with code reviews and make notes on the pad if there's info to add. I'll keep the pad updated as we progress through the rest of the cycle. Cheers, -melanie

1 0

[tc][forum] Summary for "community outreach when cultures, time zones, and languages differ" session
by Julia Kreger 10 Dec '18

10 Dec '18

Leading up to the Summit a number of us in the TC discussed how to improve outreach and thus communications outside of what we would consider our normal circles. The focus was how to better enable asynchronous communication. How do we share context? Ultimately we are talking about bridge building. The discussion went in many directions and we kind of started out discussing items that make our preferred communication methods a bit difficult. Thierry really focused us back to reality pointing out that "the earth is round". As the community has recognized before, time zones are absolutely a thing and that we shouldn't try and force people to be up at 3 AM to attend a meeting every week. As this discussion went on, a number of note worthy ideas began to surface. * Teams should likely reconsider meeting times periodically. Some teams have found success with alternating, but other teams have found that few attend the second time slot. * That it is easier to form a group of people in a specific time zone as they bring their established culture and don't have to integrate into another culture which is easier for them. The down side of this is that this leads to those people focusing on that specific project. * IRC is "super-addictive". ** The real time value of IRC is recognized, however on-boarding people into it can sometimes be a time consuming effort for some projects. ** Many, the TC included, have been trying to push more deep discussions to the mailing list or having someone summarize the outcome of conversations to the mailing list. ** IRC communication is often viewed as "too fast" of a discussion if your not a native speaker of the language being used in IRC. By the time you or software translates a statement, the discussion has moved on. * No matter what we do, there are two styles of communication that we need to be mindful of both asynchronous and synchronous communication. ** Some communities, such as the Linux kernel, have adopted fully asynchronous communication to handle the fact that the world is round. ** Projects have a tendency to use any communication method available. *** Some projects use etherpads for short term status on items, where others focus on its use for thought process preservation. *** Some projects try to drive such thought processes to an IRC discussion and then that often ends up as a discussion in gerrit. A point was eventually raised that meetings can still be useful, standing issues aside, as long as context is known in advance. The advance context does allow a team to determine in advance if a meeting is even required. Todo's and what can be done! * Simple reminders have apparently helped some meeting moderators keep people in attendance. * We reached consensus to encourage moderators to provide context in advance of meetings. This is in order to assist everyone to be more informed and hopefully shorten the exercise of trying to understand the issue as opposed to understand others impressions and reaching consensus. ** We also reached consensus that moderators should cancel a meeting if there is nothing on the agenda. * We want to encourage outreach messaging. This is not just the sub-communities making themselves known to the larger community, but raising awareness of "what is going on" or "what is new?" either in a project or portion of the community. Ultimately this falls into the category of "we do not know, what we do not know" and as such it is upon all of us to attempt to better communicate where we see gaps. As for specific action items, after re-reading the notes, I think that is up to us as a community to determine our next steps. We recorded no action items so I think further discussion may be needed. Perhaps all The etherpad can be found at https://etherpad.openstack.org/p/BER-tc-community-outreach. -Julia

1 0

[neutron][ironic] Add Support for Smart NIC with baremetal
by Moshe Levi 10 Dec '18

10 Dec '18

Hi all, We started working on specs to support baremetal with smart-nic see [1] and [2]. There are some open issue and different approaches that require further discussion see [3]. To resolve them I would like to propose a meeting tomorrow , December 11th, at 15:00 UTC. For those of you interested in joining please use [4] to connect. [1] - https://review.openstack.org/#/c/582767/ [2] - https://review.openstack.org/#/c/619920/ [3] - https://etherpad.openstack.org/p/BER-ironic-smartnics [4] - https://bluejeans.com/u/jkreger Thanks, Moshe (moshele)

1 0

On trust and risk, Australia's Assistance and Access Bill
by Jeremy Stanley 10 Dec '18

10 Dec '18

I've seen concern expressed in OpenStack and other free/libre open source software communities over the recent passage of the "Assistance and Access Bill 2018" by the Australian Parliament, and just want to say that I appreciate the trust relationships we've all built with our colleagues in many countries, including Australia. As someone who doesn't particularly agree with many of the laws passed in his own country, while I'm not going to encourage civil disobedience, I do respect that many have shown preference for it over compelled compromise of our community's established trust. I, for one, don't wish to return to the "bad old days" of the crypto wars, when major projects like OpenBSD refused contributions from citizens and residents of the USA. It's bad for project morale, excludes valuable input from people with a variety of perspectives, and it's just downright inefficient too. The unfortunate truth is that anyone can be pressured at any time to derail, backdoor or otherwise compromise software and systems. A new law in one country doesn't change that. There are frequent news stories about government agencies installing covert interfaces in enterprise and consumer electronic devices alike through compulsion of those involved in their programming, manufacture and distribution. There's evidence of major standards bodies being sidetracked and steered into unwittingly approving flawed specifications which influential actors already know ways to circumvent. Over the course of my career I've had to make personal choices regarding installation and maintenance of legally-mandated systems for spying on customers and users. All we can ever hope for is that the relationships, systems and workflows we create are as resistant as possible to these sorts of outside influences. Sure, ejecting people from important or sensitive positions within the project based on their nationality might be a way to send a message to a particular government, but the problem is bigger than just one country and we'd really all need to be removed from our posts for pretty much the same reasons. This robust community of trust and acceptance we've fostered is not a risk, it's another line of defense against erosion of our ideals and principles. Entrenched concepts like open design and public review help to shield us from these situations, and while there is no perfect protection it seems to me that secret compromise under our many watchful eyes is a much harder task than doing so behind the closed doors of proprietary systems development. I really appreciate all the Australians who toil tirelessly to make OpenStack better, and am proud to call them friends and colleagues. I certainly don't want them to feel any need to resign from their valuable work because they're worried the rest of us can no longer trust them. -- Jeremy Stanley

5 4

[k8s] K8s-SIG-OpenStack Update
by Chris Hoge 10 Dec '18

10 Dec '18

Hi everyone, a quick update on SIG-OpenStack/K8s as we head into KubeCon. To start with, today David and I are at the contributors summit and will be available to catch up on any topics you're interested in personally. The only other event we have scheduled for KubeCon is the SIG Intro session[1], Tuesday at 2:35 PM in room 3A/B. Given the smaller turnout for the deep-dive session in Copenhagen, we opted to skip the deep dive session this time around. As such, the first half of the intro will serve as the official SIG-Update, then we will reserve the end of the time for collaboration and planning. If you're involved or interested in SIG-OpenStack at all, please be sure to make this session. Following up from the OpenStack Summit, we had a productive planning session and set a number of goals and tasks[2]. Top at the list is the rotation of the SIG leadership. We're currently accepting nominations to replace David Lyle and Robert Morse. Many thanks to both for serving this last year. Currently we have nominations for * Flavio Percoco * Melvin Hillsman If you would like to be considered for SIG leadership, or would like to nominate someone, please do so in this thread or personally to me. Another item on the agenda is the rebooting of the SIG-OpenStack/K8s meetings. We will return the previously scheduled time of Wednesdays at 4 PM PT, starting January 9. I'll be sending out agendas and reminders as we get closer to the date, and will be asking some sub-project owners to attend and contribute updates. Work on the cloud provider and associated code has been moving well, and the external provider has moved well beyond the capabilities of the now-deprecated in-tree provider. If you haven't started your migration plan off of the in-tree code, please start doing so now. We're targeting full removal in 2019. The OpenStack provider for the new Cluster API has started, and we are looking for more developers to get involved. This, and a possible Ironic provider, are important for the SIG to be involved with in the coming year. If SIG-Cluster-Lifecycle reaches its goals, the Cluster API will be one of the most valuable developments for operators and users in 2019. Finally, I continue to engage with SIG-Cloud-Provider as a co-lead to advocate for consistent provider development. One of the original goals was to wind down all provider SIGS. However, as the SIGs move beyond just provider code to larger support of a user and developer community, this plan is being reconsidered. I'll keep you updated on the developments. Thanks to everyone for your ongoing contributions, and I'm looking forward to seeing the folks who are attending KubeCon in Seattle. -Chris [1] Intro OpenStack SIG: https://sched.co/Grbk [2] SIG-K8s Berlin Summit Session: https://etherpad.openstack.org/p/sig-k8s-2018-berlin-summit

1 0

Re: [openstack-dev] [nova][cinder][qa] Should we enable multiattach in tempest-full?
by Ghanshyam Mann 10 Dec '18

10 Dec '18

---- On Tue, 02 Oct 2018 00:28:51 +0900 Matt Riedemann <mriedemos(a)gmail.com> wrote ---- > On 10/1/2018 8:37 AM, Ghanshyam Mann wrote: > > +1 on adding multiattach on integrated job. It is always good to cover more features in integrate-gate instead of separate jobs. These tests does not take much time, it should be ok to add in tempest-full [1]. We should make only really slow test as 'slow' otherwise it should be fine to run in tempest-full. > > > > I thought adding tempest-slow on cinder was merged but it is not[2] > > > > [1]http://logs.openstack.org/80/606880/2/check/nova-multiattach/7f8681e/job-… > > [2]https://review.openstack.org/#/c/591354/2 > > Actually it will be enabled in both tempest-full and tempest-slow, > because there is also a multiattach test marked as 'slow': > TestMultiAttachVolumeSwap. > > I'll push patches today. While reviewing your patch and checking multiattach slow test on stable branch as part of tempest-slow job, I found that tempest-slow (tempest-multinode-full) job does not run on nova stable branches (even nova .zuul.yaml has that job to run for stable branch) which we can say bug on Tempest side because tempest-slow job definition is to run only on master [1]. I am trying to enable that for all stable branches[2]. I am getting few failure on tempest-slow (tempest-multinode-full) for stable branches which might take time to fix and till then let's keep nova-multiattach on stable branches and remove only for master. [1] https://github.com/openstack/tempest/blob/a32467c4c515dff325e6b4b5ce7af24a0… [2] https://review.openstack.org/#/q/topic:tempest-multinode-slow-stable+(statu… -gmann > > -- > > Thanks, > > Matt > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >

2 2

Openstacl magnum Queens api error
by Ignazio Cassano 10 Dec '18

10 Dec '18

Hi All, I installed magnum in queens with Centos 7 and I am facing with the same issue descrive here: https://bugs.launchpad.net/magnum/+bug/1701381 Please, anyone solved it? Regards Ignazio

1 1

[charms] No meetings until January 7th
by Frode Nordahl 10 Dec '18

10 Dec '18

Dear charmers and community at large, We will be taking a break from our weekly meetings and will reconvene after the holidays. First weekly meeting will be Monday January 7th. In the meantime, do not hesitate to contact us in #openstack-charmers on Freenode or by sending e-mail to the OpenStack Discuss mailinglist using the [charms] tag in the subject line. Cheers all! -- Frode Nordahl

2 1