- openstack-discuss - lists.openstack.org

[tc][all] Train Community Goals
by Lance Bragstad 15 Feb '19

15 Feb '19

Hi all, The purpose of this thread is to have a more focused discussion about what we'd like to target for Train community goals, bootstrapped with the outcomes from the session in Berlin [0]. During the session, we went through each item as a group and let the person who added it share why they thought it would be a good community goal candidate for the next release. Most goals have feedback captured in etherpad describing next steps, but the following stuck out as top contenders from the session (rated by upvotes): 1. Moving legacy clients to python-openstackclient 2. Cleaning up resources when deleting a project 3. Service-side health checks I don't think I missed any goals from the session, but if I did, please let me know and I'll add it to the list so that we can discuss it here. Does anyone have strong opinions either way about the goals listed above? [0] https://etherpad.openstack.org/p/BER-t-series-goals

15 26

[kayobe] Kayobe 5.0.0 released
by Mark Goddard 15 Feb '19

15 Feb '19

Hi, I'm pleased to announce the release of Kayobe 5.0.0. This release supports deployment of OpenStack Rocky. Lots of new features and fixes, see [1]. Thanks to everyone who contributed. Now onto Stein - we're catching up! [1] https://kayobe-release-notes.readthedocs.io/en/latest/rocky.html Mark

1 0

[nova][dev] 3 weeks until feature freeze
by melanie witt 15 Feb '19

15 Feb '19

Howdy all, We've about 3 weeks left until feature freeze milestone s-3 on March 7: https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule Non-client library freeze is in 2 weeks February 28, so if you need changes released in Stein for os-vif, os-traits, or os-resource-classes, they need to be merged by Feb 28 and the releases will be proposed on Feb 28. Ping us if you need review. I've updated the blueprint status tracking etherpad: https://etherpad.openstack.org/p/nova-stein-blueprint-status For our Cycle Themes: Multi-cell operational enhancements: The patch series for the API microversion for handling of down cells on the nova side has all been approved as of today. Only the python-novaclient change remains. Counting quota usage from placement is still an active WIP. Cross-cell resize is still making good progress with active code review. Compute nodes able to upgrade and exist with nested resource providers for multiple vGPU types: The libvirt driver reshaper patch has been updated today but needs some fixes for unit test failures. Volume-backed user experience and API improvement: The detach boot volume and volume-backed server rebuild patches are active WIP. If you are the owner of an approved blueprint, please: * Add the blueprint if I've missed it * Update the status if it is not accurate * If your blueprint is in the "Wayward changes" section, please upload and update patches as soon as you can, to allow maximum time for review * If your patches are noted as Merge Conflict or WIP or needing an update, please update them and update the status on the etherpad * Add a note under your blueprint if you're no longer able to work on it this cycle Let us know if you have any questions or need assistance with your blueprint. Cheers, -melanie

1 0

[cloudkitty] March IRC meeting is cancelled
by Luka Peschke 15 Feb '19

15 Feb '19

Hello everybody, Due to various people not being available on march 1st, the cloudkitty IRC meeting that was planned at that date is cancelled. The next meeting will be held on april 5th at 15h UTC / 17h CET. Cheers, -- Luka Peschke

1 0

[release][heat][tripleo][kolla][monsca] need PTL/liaison ACK on pending releases
by Doug Hellmann 15 Feb '19

15 Feb '19

We have a few pending releases that were proposed by someone who is not listed as the PTL or Liaison for the associated project. That's fine, but in those cases we need the PTL or Liaison to acknowledge and approve the release before we process it. Please take a minute today or Monday to look at these and indicate whether it is OK to release them. https://review.openstack.org/#/c/636285/ heat-translator 1.3.0 (stein) https://review.openstack.org/#/c/635569/ tripleo-heat-templates 8.3.0 (queens) https://review.openstack.org/#/c/635536/ kolla 6.1.1 (queens) https://review.openstack.org/#/c/637163/ python-monscaclient 1.13.0 (stein) -- Doug

3 3

Re: [requirements][requests] security update for requests in stable branches
by Matthew Thode 15 Feb '19

15 Feb '19

On 19-02-15 06:51:20, Boden Russell wrote: > Just to confirm; the best way to test with this change is to submit a > dummy patch that depends on 637124 in the respective project's > stable/rocky branch? > > > On 2/15/19 12:27 AM, Matthew Thode wrote: > > Recently it was reported to us that requests had a recent release that > > addressed a CVE (CVE-2018-18074). Requests has no stable branches so > > the only way to update openstack stable branches is to update to 2.20.1 > > in this case. I wanted to pass this by people as requests is generally > > a nasty library with nasty surprises. It's passed our cross and dvsm > > gating though (for rocky) so indications look good. What I'm asking you > > for is anything that could go wrong with updating (rocky in this case, > > but possibly back to newton, depending on co-installability). Please > > let me know any blockers to to update (in the review preferably). > > > > https://review.openstack.org/637124 > > > > Thanks, > > Yes -- Matthew Thode

1 0

Re: [Release-job-failures][kayobe] Pre-release of openstack/kayobe failed
by Doug Hellmann 15 Feb '19

15 Feb '19

zuul(a)openstack.org writes: > Build failed. > > - release-openstack-python http://logs.openstack.org/3b/3ba003efaf249ac62ae588310f6ad3279d65f337/pre-r… : SUCCESS in 4m 25s > - announce-release http://logs.openstack.org/3b/3ba003efaf249ac62ae588310f6ad3279d65f337/pre-r… : SUCCESS in 4m 40s > - propose-update-constraints http://logs.openstack.org/3b/3ba003efaf249ac62ae588310f6ad3279d65f337/pre-r… : SUCCESS in 4m 14s > - trigger-readthedocs-webhook http://logs.openstack.org/3b/3ba003efaf249ac62ae588310f6ad3279d65f337/pre-r… : FAILURE in 1m 58s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures It looks like maybe the kayobe project integration with readthedocs is broken. The log output [1] is suppressed, so I can't actually see the error to provide more details. Please work with the infra team to address this issue. [1] http://logs.openstack.org/3b/3ba003efaf249ac62ae588310f6ad3279d65f337/pre-r… -- Doug

1 0

[sig][upgrades] IRC meeting Monday 18th->25th
by James Page 15 Feb '19

15 Feb '19

Hi All In a feat of random planning weirdness, both the last and the upcoming Upgrades SIG IRC meeting days have landed on a US holiday. As the last one was a bit of a flop due to this co-incidence I'm proposing we bump back one week and move the IRC meetings from the 18th->25th February. They will be at 0900 and 1600 UTC as usual to cover as many participants as possible! If you're based on the US - have a lovely Presidents day! Cheers James

1 0

kayobe 5.0.0.0rc1 (rocky)
by no-reply＠openstack.org 15 Feb '19

15 Feb '19

Hello everyone, A new release candidate for kayobe for the end of the Rocky cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/kayobe/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Rocky release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/rocky release branch at: https://git.openstack.org/cgit/openstack/kayobe/log/?h=stable/rocky Release notes for kayobe can be found at: https://docs.openstack.org/releasenotes/kayobe/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/openstack/kayobe and tag it *rocky-rc-potential* to bring it to the kayobe release crew's attention.

1 0

Re: [keystone] adfs SingleSignOn with CLI/API?
by Colleen Murphy 15 Feb '19

15 Feb '19

Forwarding back to list On Mon, Feb 11, 2019, at 5:11 PM, Blake Covarrubias wrote: > > On Feb 11, 2019, at 6:19 AM, Colleen Murphy <colleen(a)gazlene.net> wrote: > > > > Hi Fabian, > > > > On Mon, Feb 11, 2019, at 12:58 PM, Fabian Zimmermann wrote: > >> Hi, > >> > >> Im currently trying to implement some way to do a SSO against our > >> ActiveDirectory. I already tried SAMLv2 and OpenID Connect. > >> > >> Im able to sign in via Horizon, but im unable to find a working way on cli. > >> > >> Already tried v3adfspassword and v3oidcpassword, but im unable to get > >> them working. > >> > >> Any hints / links / docs where to find more information? > >> > >> Anyone using this kind of setup and willing to share KnowHow? > >> > >> Thanks a lot, > >> > >> Fabian Zimmermann > > > > We have an example of authenticating with the CLI here: > > > > https://docs.openstack.org/keystone/latest/admin/federation/configure_feder… > > > > That only covers the regular SAML2.0 ECP type of authentication, which I guess won't work with ADFS, and we seem to have zero ADFS-specific documentation. > > > > From the keystoneauth plugin code, it looks like you need to set identity-provider-url, service-provider-endpoint, service-provider-entity-id, username, password, identity-provider, and protocol (I'm getting that from the loader classes[1][2]). Is that the information you're looking for, or can you give more details on what specifically isn't working? > > > > Colleen > > > > [1] http://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/loa… > > [2] http://git.openstack.org/cgit/openstack/keystoneauth/tree/keystoneauth1/ext… > > > > Fabian, > > To add a bit more info, the AD FS plugin essentially uses IdP-initiated > sign-on. The identity provider URL is where the initial authentication > request to AD FS will be sent. An example of this would be > https://HOSTNAME/adfs/services/trust/13/usernamemixed > <https://hostname/adfs/services/trust/13/usernamemixed>. The service > provider’s entity ID must also be sent in the request so that AD FS > knows which Relying Party Trust to associate with the request. > > AD FS will provide a SAML assertion upon successful authentication. The > service provider endpoint is the URL of the Assertion Consumer Service. > If you’re using Shibboleth on the SP, this would be > https://HOSTNAME/Shibboleth.sso/ADFS > <https://hostname/Shibboleth.sso/ADFS>. > > Note: The service-provider-entity-id can be omitted if it is the same > value as the service-provider-endpoint (or Assertion Consumer Service > URL). > > Hope this helps. > > — > Blake Covarrubias >

3 5