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

[placement] delegations and liaisons
by Chris Dent 21 Mar '19

21 Mar '19

There are several different liaison roles for handling cross project issues. They are listed on the wiki at https://wiki.openstack.org/wiki/CrossProjectLiaisons The default liaison is the PTL but it is common and healthy to delegate to other team members. There are lots of different cross-projects listed on that page, with varying degrees of activity within the group and responsibilities for the liaison. Release, Stable, and Vulnerability are fairly key. If you're working on placement and are interested in taking on one of these roles, please let me know and we can update the wiki page. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 2

cinder 14.0.0.0rc1 (stein)
by no-reply＠openstack.org 21 Mar '19

21 Mar '19

Hello everyone, A new release candidate for cinder for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cinder/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/cinder/log/?h=stable/stein Release notes for cinder can be found at: https://docs.openstack.org/releasenotes/cinder/

1 0

octavia 4.0.0.0rc1 (stein)
by no-reply＠openstack.org 21 Mar '19

21 Mar '19

Hello everyone, A new release candidate for octavia for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/octavia/log/?h=stable/stein Release notes for octavia can be found at: https://docs.openstack.org/releasenotes/octavia/

1 0

ceilometer-powervm 8.0.0.0rc1 (stein)
by no-reply＠openstack.org 21 Mar '19

21 Mar '19

Hello everyone, A new release candidate for ceilometer-powervm for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/ceilometer-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/ceilometer-powervm/log/?h=stable/s… Release notes for ceilometer-powervm can be found at: https://docs.openstack.org/releasenotes/ceilometer-powervm/

1 0

networking-powervm 8.0.0.0rc1 (stein)
by no-reply＠openstack.org 21 Mar '19

21 Mar '19

Hello everyone, A new release candidate for networking-powervm for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/networking-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/networking-powervm/log/?h=stable/s… Release notes for networking-powervm can be found at: https://docs.openstack.org/releasenotes/networking-powervm/

1 0

[release] Release countdown for week R-2, March 25-29
by Sean McGinnis 21 Mar '19

21 Mar '19

Hard to believe we are already at R-2. The next couple weeks will go by fast. Development Focus ----------------- Teams should be working on any release critical bugs that would require another RC before the final release, and thinking about plans for Train. General Information ------------------- The release team has proposed RC1 releases for all cycle-with-rc deliverables. Thank you to all who either acknowledged readiness with a +1 or updated those to pick up any remaining commits needed for a good RC. For those that have not had a response, in order to have a good branching point for stable/stein, we will be approving the remaining patches on March 22. Any further changes needed for Stein will need to be merged to master and backported to stable/stein and a new RC requested. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them back up for Train development, though the focus should still be on finishing up Rocky until the final release. Actions --------- Watch for any translation patches coming through and merge them quickly. If your project has a stable/stein branch created, please make sure those patches are also merged there. Keep in mind there will need to be a final release candidate cut to capture any merged translations and critical bug fixes from this branch. Please also check for completeness in release notes and add any relevant "prelude" content. These notes are targetted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the Stein version of your project. We also have the cycle-highlights information in the project deliverable files. This one is targeted at marketing and other consumers that have typically been pinging PTLs every release asking for "what's new" in this release. If you have not done so already, please add a few highlights for your team that would be useful for this kind of consumer. After RC1 week, it is not likely that any information will be used for our initial Press Release that goes out with the final release, but it could still be useful for any other outside consumer looking at these for the high level highlights of the release. This would be a good time for any release:independent projects to add the history for any releases not yet listed in their deliverable file. These files are under the deliverable/_independent directory in the openstack/releases repo. If you have a cycle-with-intermediary release that has merged changes since the last release, please propose a new one as soon as possible. If we do not receive release requests for these repos soon we will be forced to create a release from the latest commit to create a stable/stein branch. The release team would rather not be the ones initiating this release. Upcoming Deadlines & Dates -------------------------- Final RC deadline: April 1 Final Stein release: April 10 -- Sean McGinnis (smcginnis)

1 0

[senlin] Senlin Monthly(ish) Newsletter March 2019
by Duc Truong 21 Mar '19

21 Mar '19

Senlin Monthly(ish) Newsletter ============================== HTML: https://dkt26111.wordpress.com/2019/03/21/senlin-monthlyish-newsletter-marc… This is the March edition of the Senlin monthly(ish) newsletter. The goal of the newsletter is to highlight happenings in the Senlin project. If you have any feedback or questions regarding the contents, please feel free to reach out to me in the #senlin IRC channel. News ---- * Congratulations to Xuefeng Liu for returning as PTL for Train. * This is probably the last Senlin newsletter for awhile as we have reached the end of my PTL term for the Stein cycle. I have enjoyed serving as the PTL for the past cycle and look to continue contributing to Senlin in Train. * Senlin release candidate for Stein 7.0.0.0rc1 is now available: https://releases.openstack.org/stein/#stein-senlin * Congratulations to Jude Cross and Erik Olof Gunnar Andersson on joining Senlin Stable Maintainers. Denver Summit 2019 ------------------ The following Senlin related sessions will be held at the Denver summit: * Senlin Project Update https://www.openstack.org/summit/denver-2019/summit-schedule/events/23636/s… * Auto Scaling SIG Initial Discussion https://www.openstack.org/summit/denver-2019/summit-schedule/events/23625/a… * Senlin Project Onboarding https://www.openstack.org/summit/denver-2019/summit-schedule/events/23647/s… * How Blizzard Entertainment Uses Autoscaling with Overwatch https://www.openstack.org/summit/denver-2019/summit-schedule/events/23379/h… Jude Cross and I will also be attending the PTG following the summit. If you have anything to discuss, please reach out to us.

1 0

[senlin][stable] Senlin Stable Maintainers Team Nominations
by Duc Truong 21 Mar '19

21 Mar '19

Hi Senlin Stable Team, I would like to nominate Jude Cross and Erik Olof Gunnar Andersson to the Senlin stable review team. Both have been doing stable reviews and shown that they understand the policy for merging stable patches [1]. Voting is open for 7 days. Please reply with your +1 vote in favor or -1 as a veto vote. [1] https://review.openstack.org/#/q/(project:openstack/senlin+OR+openstack/sen… Regards, Duc (dtruong)

2 2

Re: [openstack-dev] [TripleO] easily identifying how services are configured
by Emilien Macchi 21 Mar '19

21 Mar '19

[top-posting] While the flattening / moving work has made huge progress (thanks Dan for driving this effort!), I think it's time to agree if whether or not we backport the deployment directory for now. For new services added in Stein, which need to be backported in stable versions, they'll have to be backported with merge conflict & dealt with it. For bug fixes in existing services, we'll have to backport to stable branches with small merge conflict but if we backported the deployment directory, I think the conflicts would be bigger since stable branches would miss all the flattening/moving work (IMHO too big to backport). So I propose that we - do not backport deployment directory - deal with small merge conflicts when backporting patches in existing services - for new stein services, and when backport needed, put them in either docker or puppet directories in rocky and backport to queens eventually. Feedback is open. Thanks, On Thu, Oct 25, 2018 at 6:06 PM Dan Prince <dprince(a)redhat.com> wrote: > On Wed, Oct 17, 2018 at 11:15 AM Alex Schultz <aschultz(a)redhat.com> wrote: > > > > Time to resurrect this thread. > > > > On Thu, Jul 5, 2018 at 12:14 PM James Slagle <james.slagle(a)gmail.com> > wrote: > > > > > > On Thu, Jul 5, 2018 at 1:50 PM, Dan Prince <dprince(a)redhat.com> wrote: > > > > Last week I was tinkering with my docker configuration a bit and was > a > > > > bit surprised that puppet/services/docker.yaml no longer used puppet > to > > > > configure the docker daemon. It now uses Ansible [1] which is very > cool > > > > but brings up the question of how should we clearly indicate to > > > > developers and users that we are using Ansible vs Puppet for > > > > configuration? > > > > > > > > TripleO has been around for a while now, has supported multiple > > > > configuration ans service types over the years: os-apply-config, > > > > puppet, containers, and now Ansible. In the past we've used rigid > > > > directory structures to identify which "service type" was used. More > > > > recently we mixed things up a bit more even by extending one service > > > > type from another ("docker" services all initially extended the > > > > "puppet" services to generate config files and provide an easy > upgrade > > > > path). > > > > > > > > Similarly we now use Ansible all over the place for other things in > > > > many of or docker and puppet services for things like upgrades. That > is > > > > all good too. I guess the thing I'm getting at here is just a way to > > > > cleanly identify which services are configured via Puppet vs. > Ansible. > > > > And how can we do that in the least destructive way possible so as > not > > > > to confuse ourselves and our users in the process. > > > > > > > > Also, I think its work keeping in mind that TripleO was once a multi- > > > > vendor project with vendors that had different preferences on service > > > > configuration. Also having the ability to support multiple > > > > configuration mechanisms in the future could once again present > itself > > > > (thinking of Kubernetes as an example). Keeping in mind there may be > a > > > > conversion period that could well last more than a release or two. > > > > > > > > I suggested a 'services/ansible' directory with mixed responces in > our > > > > #tripleo meeting this week. Any other thoughts on the matter? > > > > > > I would almost rather see us organize the directories by service > > > name/project instead of implementation. > > > > > > Instead of: > > > > > > puppet/services/nova-api.yaml > > > puppet/services/nova-conductor.yaml > > > docker/services/nova-api.yaml > > > docker/services/nova-conductor.yaml > > > > > > We'd have: > > > > > > services/nova/nova-api-puppet.yaml > > > services/nova/nova-conductor-puppet.yaml > > > services/nova/nova-api-docker.yaml > > > services/nova/nova-conductor-docker.yaml > > > > > > (or perhaps even another level of directories to indicate > > > puppet/docker/ansible?) > > > > > > Personally, such an organization is something I'm more used to. It > > > feels more similar to how most would expect a puppet module or ansible > > > role to be organized, where you have the abstraction (service > > > configuration) at a higher directory level than specific > > > implementations. > > > > > > It would also lend itself more easily to adding implementations only > > > for specific services, and address the question of if a new top level > > > implementation directory needs to be created. For example, adding a > > > services/nova/nova-api-chef.yaml seems a lot less contentious than > > > adding a top level chef/services/nova-api.yaml. > > > > > > It'd also be nice if we had a way to mark the default within a given > > > service's directory. Perhaps services/nova/nova-api-default.yaml, > > > which would be a new template that just consumes the default? Or > > > perhaps a symlink, although it was pointed out symlinks don't work in > > > swift containers. Still, that could possibly be addressed in our plan > > > upload workflows. Then the resource-registry would point at > > > nova-api-default.yaml. One could easily tell which is the default > > > without having to cross reference with the resource-registry. > > > > > > > So since I'm adding a new ansible service, I thought I'd try and take > > a stab at this naming thing. I've taken James's idea and proposed an > > implementation here: > > https://review.openstack.org/#/c/588111/ > > > > The idea would be that the THT code for the service deployment would > > end up in something like: > > > > deployment/<service>/<specific-service-element>-<implementation>.yaml > > A matter of preference but I can live with this. > > > > > Additionally I took a stab at combining the puppet/docker service > > definitions for the aodh services in a similar structure to start > > reducing the overhead we've had from maintaining the docker/puppet > > implementations seperately. You can see the patch > > https://review.openstack.org/#/c/611188/ for an additional example of > > this. > > > > Please let me know what you think. > > I'm okay with it in that it consolidates some things (which we greatly > need to do). It does address my initial concern in that people are now > putting Ansible services into the puppet/services directory albeit a > bit heavy handed in that it changes everything (rather than just the > new Ansible services). Understood that you are also eliminating the > "inheritance" from the docker/services to the puppet/services files... > by simply eliminating the Puppet varients. I had hoped to implement a > baremetal Packstack like installer (still somewhat popular) with t-h-t > but there doesn't appear to be anyone in the Packstack camp speaking > up for the idea here. So much for consolidation. There doesn't seem to > be anyone else in TripleO (aside from myself) who wants baremetal so I > guess be gone with it. Opportunity to test on baremetal lost! Like we > discussed we could have easily kept both and used jinja templates to > avoid the "inheritance" across the baremetal(puppet) and > docker/services and thus also minimized our Heat resources which have > grown. There *are* ways to implement this addressing all concerns and > keeping both features. We are choosing not do this however. > > I see people are already +2'ing the patches so it appears to have been > decided. But, Are we going to commit to trying to move all the > existing services to this new format within a release? There are 200 > or so t-h-t patches up for review that would likely need rebased. And > yes this will make backports more difficult as well. > > In all this is we are changing our entire directory structure but not > really removing any dependencies. I suppose if we are going to do the > work I'd rather see us drop some dependencies in the process too :/. > Where destructive meets productive is our best investment I think. > > Dan > > > > > Thanks, > > -Alex > > > > > > > > -- > > > -- James Slagle > > > -- > > > > > > > __________________________________________________________________________ > > > 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 > > > > > __________________________________________________________________________ > > 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 > > __________________________________________________________________________ > 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 > -- Emilien Macchi

2 1

[neutron] functional and fullstack jobs are broken currently
by Slawomir Kaplonski 21 Mar '19

21 Mar '19

Hi, Because of bug [1] all neutron-functional and neutron-fullstack jobs will now be failing with RETRY_LIMIT. It should be fixed by [2] so please don’t recheck your patches now. When patch [2] will be merged I will update here and You will need to rebase Your patches to get it working on Your patch. [1] https://launchpad.net/bugs/1820993 [2] https://review.openstack.org/#/c/644842/ — Slawek Kaplonski Senior software engineer Red Hat

1 1