- openstack-discuss - lists.openstack.org

[keystone] anyone using OpenID with Keystone?
by Francois 16 Feb '22

16 Feb '22

Hi Keystone users! I am wondering if anyone has experience with keystone openid integration. Initially I was using Keystone LDAP backend (using tripleo KeystoneLDAPDomainEnable and KeystoneLDAPBackendConfigs parameters) and it works! Users are able to log in through Horizon or through the cli, roles can be given per LDAP group, and you can click in Horizon and download a working openrc or clouds.yaml file (minus the root CA that has to be added) to authenticate with the cli (and your password ends as an OS_PASSWORD variable in your environment). I am now trying the Keystone Openid backend (using the enable-federation-openidc.yaml provided by tripleo - https://github.com/openstack/tripleo-heat-templates/blob/master/environment…) with a mapping like this: [{"local":[{"user":{"name":"{0}"},"group":{"domain":{"name":"Default"},"name":"federated_users"}}],"remote":[{"type":"HTTP_OIDC_EMAIL"}]}] The SSO works superb with Horizon, however - logging with the cli seems impractical. I see some doc here: https://docs.ukcloud.com/articles/openstack/ostack-how-use-api-sso.html where you need to provide a secret, I am skeptical I want to do that. The openrc file downloaded from Horizon is not usable as is and needs some tuning. And there is no SSO, and the password still ends up in the environment... - I don't see how I can grant roles to groups anymore. It seems I need an extra mechanism to grant permissions (as I used to do that using LDAP groups). I am wondering if anyone is willing to share their experience dealing with Keystone and OpenID. Thanks! Francois (frigo)

5 5

Openstack HPC Infiniband question
by Satish Patel 16 Feb '22

16 Feb '22

Hi all, I am playing with HPC on openstack cloud deployment and I have a Mellanox infiniband nic card. I have a couple of deployment questions regarding the infiniband network. I am new to ib so excuse me if i ask noob questions. I have configured Mellanox for sriov and created a flavor with the property pci_passthrough:alias='mlx5-sriov-ib:1' to expose VF to my instance. so far so good and i am able to see the ib interface inside my vm and its active. (I am running SM inside infiniband HW switch) root@ib-vm:~# ethtool -i ibs5 driver: mlx5_core[ib_ipoib] version: 5.5-1.0.3 firmware-version: 20.28.1002 (MT_0000000222) expansion-rom-version: bus-info: 0000:00:05.0 supports-statistics: yes supports-test: yes supports-eeprom-access: no supports-register-dump: no supports-priv-flags: yes I didn't configure any ipaddr on the ibs5 interface etc. For testing purposes I have compiled mpirun hello world program to POC my infiniband network between two instances and I am able to successfully run the mpi sample program. Somewhere i read about neutron-mellanox agent to setup IPoIB for segmentation etc but not very sure that how complex it and what are the advantage here over just using simple passthru of SR-IOV Is this the correct way to set up an HPC cluster using openstack or is there a better way to design HPC on openstack?

2 2

[all][elections][tc] TC Election Campaigning Kickoff
by Ghanshyam Mann 16 Feb '22

16 Feb '22

Community Members, The TC Election Campaigning Period has now started [1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms [2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform [2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. Even though there are no runoffs, still it is good to have campaigning discussion. [1] https://governance.openstack.org/election/ [2] https://governance.openstack.org/election/#z-tc-candidates -gmann & The OpenStack Technical Election Officials

1 0

[all][elections][ptl][tc] Combined PTL/TC Zed cycle Election Nominations End
by Ghanshyam Mann 16 Feb '22

16 Feb '22

Hello Everyone, The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 17 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant, Freezer, Heat, Magnum, Masakari, Monasca, Murano, OpenStack_Charms, Openstack_Chef, Senlin, Skyline, Solum, Trove, Venus, Watcher, Zaqar, Zun There are 0 projects that will have elections. -- TC Election Details -- The 5 seats were filled and no runoff is required. Now begins the campaigning period where candidates and electorate may debate their statements. Thank you, [0] https://governance.openstack.org/election/#z-ptl-candidates [1] https://governance.openstack.org/election/#z-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for… -gmann & The OpenStack Technical Election Officials

1 0

Create Image in queue State in XENA Version
by Adivya Singh 16 Feb '22

16 Feb '22

Hi Team, We have lately upgraded to Xena , but when users trying to upload any image, it is always in queue state, i did not see any error regarding any issue with glance configuration file. Any thoughts on this Regards Adivya Singh

2 1

[tooz] [mistral] Tenacity >= 8.0.1 issues (in Debian)
by Thomas Goirand 16 Feb '22

16 Feb '22

Hi, It seems Tenacity has some incompatible changes leading to this: https://bugs.debian.org/1005636 (tooz) https://bugs.debian.org/1005467 (mistral) Note that both Manila and Heat were fixed already for this last version of Tenacity, so these would likely be the only remaining blockers to upgrade to 8.0.1. As Tenacity 8.0.1 is already in Debian Unstable, I'd prefer if we fixed these rather than pinning to a lower version. Can anyone help? Cheers, Thomas Goirand (zigo)

2 2

[cinder] final reviews needed for os-brick yoga release
by Brian Rosmaita 16 Feb '22

16 Feb '22

Hello Argonauts, We are now aiming to release on Tuesday 15 Feb at 20:00 UTC. The list of patches needing review and some comments on their status is here: https://etherpad.opendev.org/p/os-brick-yoga-release We're in mostly good shape, just need a final sprint to close this out. reviewers: please review! patch authors: please keep an eye on your patches and respond quickly and make sure your CI has responded with success thanks, brian

1 1

[election][Requirements] PTL candidacy for Zed
by Matthew Thode 16 Feb '22

16 Feb '22

I would like to announce my candidacy for PTL of the Requirements project for the Zed cycle. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible (stuff like prettytable). 3. Fix some automation of generate contstraints (pkg-resources being added and setuptools being dropped) 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. 5. introduce better python version range support into constraints. I look forward to continue working with you in this cycle, as your PTL or not. Thanks for your time, -- Matthew Thode

1 0

[election][swift] PTL candidacy for Zed
by Timothy Burke 16 Feb '22

16 Feb '22

I intend to continue serving as Swift PTL for the Zed cycle. We have seen Swift scale in spectacular ways. Hard drives have grown from 2-4 terabytes when Swift was started to 10-20T. The idea of a "large cluster" has gone from dozens of petabytes across hundreds of nodes to hundreds of petabytes across thousands of nodes. We will continue to see (and address) new challenges in scaling Swift. We anticipate hitting the bounds of our current ring format. We see operators struggle to balance the prioritization of cluster expansion and data durability. We see the need to improve sharding, so that clients are less impacted by what's going on in the backend. All of these have seen progress in the last cycle, and will continue to be advanced in the next. Just as important as scaling the core storage platform, however, is building up the ecosystem of ancillary services that users have come to expect out of their object storage. When a container grows to have billions of objects, it is impractical to perform thousands of listing requests to analyze its contents; instead, users expect a periodic inventory that's easy to pull into their existing data pipelines. Users should be able to examine their own access logs rather than needing to involve operators. Users want to manage their data movement and retention en masse rather than object-by-object. I look forward to seeing the balance we strike between enhancing the core storage platform and building out the data services surrounding it over the coming years. Tim Burke

1 0

[election][Release_Management] PTL candidacy for Z cycle
by Előd Illés 16 Feb '22

16 Feb '22

Hello OpenStack Community, I would like to announce my candidacy for the PTL role of the Release Management team for the Z cycle. I am core member in the Release Management team since Wallaby, but I followed the team's work even before that, and I also have been the PTL of the team for Yoga cycle for some months now. (Though, from release management perspective this is not a long period, since the most laborous part will only start in the coming weeks ;)) Furthermore, as in the past, beside release management duties, my focus is still on stable maintenance as well, since I am stable-maint-core member, too. The next cycle's challenges will be to prepare our tooling to alphabet roll-over after the Z cycle and to adjust to any other changes in our processes. And of course, parallel to this, to release OpenStack Z :) Thanks for your consideration, Előd Illés (elodilles)

1 0