October 2019 - openstack-discuss - lists.openstack.org

[auto-scaling] SIG PTG schedule. please join us :)
by Rico Lin 02 Nov '19

02 Nov '19

Hi all PTG is right next week, so if you're interested in Auto-scaling features, please join us. Our session will be hosted on 11/6 for Half-day from 9:00 am to 12:30 pm in room 431. You can suggest PTG sessions in our etherpad: https://etherpad.openstack.org/p/PVG-auto-scaling-sig Feel free to join our IRC channel as well: #openstack-auto-scaling Also, you can check out our new documents for autoscaling: https://docs.openstack.org/auto-scaling-sig And provide any feedback/ bug report for any Auto-scaling issue related to OpenStack in https://storyboard.openstack.org/#!/project/openstack/auto-scaling-sig Here's my Wechat ID: RicoLinCloudGeek See you all in Shanghai! -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 2

[cinder] changing the weekly meeting time
by Brian Rosmaita 02 Nov '19

02 Nov '19

(Just to be completely clear -- we're only gathering information at this point. The Cinder weekly meeting is still Wednesdays at 16:00 UTC.) As we discussed at today's meeting [0], a request has been made to hold the weekly meeting earlier so that it would be friendlier for people in Asia time zones. Based on the people in attendance today, it seems that a move to 14:00 UTC is not out of the question. Thus, the point of this email is to solicit comments on whether we should change the meeting time to 14:00 UTC. As you consider the impact on yourself, if you are in a TZ that observes Daylight Savings Time, keep in mind that most TZs go back to standard time over the next few weeks. (I was going to insert an opinion here, but I will wait and respond in this thread like everyone else.) cheers, brian [0] http://eavesdrop.openstack.org/meetings/cinder/2019/cinder.2019-10-23-16.00…

3 3

[keystone] Federated users who wish to use CLI
by Jason Anderson 31 Oct '19

31 Oct '19

Hi all, I'm in the process of prototyping a federated Keystone using OpenID Connect, which will place ephemeral users in a group that has roles in existing projects. I was testing how it felt from the user's perspective and am confused how I'm supposed to be able to use the openstacksdk with federation. For one thing, the RC files I can download from the "API Access" section of Horizon don't seem like they work; the domain is hard-coded to "Federated", and it also uses a username/password authentication method. I can see that there is a way to use KSA to use an existing OIDC token, which I think is probably the most "user-friendly" way, but the user still has to obtain this token themselves out-of-band, which is not trivial. Has anybody else set this up for users who liked to use the CLI? Is the solution to educate users about creating application credentials instead? Thank you in advance, -- Jason Anderson Chameleon DevOps Lead Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory

4 8

Permamently delete double / wrong openflow entry from br-tun bridge in OpenvSwitch
by Pawel Konczalski 31 Oct '19

31 Oct '19

Hi, i have a VM with ARP entries in both OpenVswitch bridges br-tun and br-int on the compute node where is it executed: ovs-ofctl dump-flows br-int | egrep "arp.*10.20.0.34" cookie=0x117c25cd8a3f96, duration=47029.368s, table=24, n_packets=20, n_bytes=840, priority=2,arp,in_port="qvod9cdff27-9c",arp_spa=10.20.0.34 actions=resubmit(,25) ovs-ofctl dump-flows br-tun | egrep "arp.*10.20.0.34" cookie=0x1597c76aa2fd74f2, duration=47015.961s, table=21, n_packets=0, n_bytes=0, priority=1,arp,dl_vlan=27,arp_tpa=10.20.0.34 ... 3e:42:af:1d,IN_PORT The unnecassary / faulty entry can by deleted manually from br-tun with: ovs-ofctl --strict del-flows br-tun "priority=1,arp,dl_vlan=27,arp_tpa=10.20.0.34" but after the port is shutdown and up again the entry will by recreated again. When the VM is moved to another compute node, only the br-int entry is created, moving back to the initial host creates both again. Any idea how to remove permamenty this br-tun entry? Thanks Pawel

1 0

[nova] No meeting during summit/PTG week
by Eric Fried 31 Oct '19

31 Oct '19

And that's all I have to say about that. https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting

1 0

[security] Security SIG Newsletter - Oct 31st 2019
by Gage Hugo 31 Oct '19

31 Oct '19

Hello everyone, Due to a hectic October, this newsletter will have the updates for the month. The SIG meetings for the 07th, 21st, and 28th in November will be cancelled as well due to Summit/PTG & Holidays. Have a Happy Halloween! #Date: 31 Oct 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Meeting Notes (October) - fungi volunteers to be nova spec liaison for ussuri image encryption spec in nova: http://eavesdrop.openstack.org/meetings/image_encryption/2019/image_encrypt… - The Security SIG won't be meeting on the following dates in November due to the Summit/PTG & Holidays - Nov 07th, Nov 21st, Nov 28th #VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - OSSA-2019-005 was released this month: https://security.openstack.org/ossa/OSSA-2019-005.html - ceph backend, secret key leak: https://bugs.launchpad.net/cinder/+bug/1849624 - CSV Injection Possible in Compute Usage History: https://bugs.launchpad.net/horizon/+bug/1842749

1 0

[tc][all][goal]: Ussuri community goal candidate 3: 'Consistent and secure default policies'
by Ghanshyam Mann 31 Oct '19

31 Oct '19

Hello Everyone, This is 3rd proposal candidate for the Ussuri cycle community-wide goal. The other two are [1]. Colleen proposed this idea for the Ussuri cycle community goal. Projects implemented/plan to implement this: *Keystone already implemented this with all necessary support in oslo.policy with nice documentation. * We discussed this in nova train PTG to implement it in nova [2]. Nova spec was merged in Train but could not implement. I have re-proposed the spec for the Ussuri cycle [3]. This is nice idea as a goal from the user perspective. Colleen has less bandwidth to drive this goal alone. We are looking for a champion or co-champions (1-2 people will be much better) this goal along with Colleen. Also, let us know what do you think of this as a community goal? Any query or Improvement Feedback? You can refer the detailed on etherpad or I am copying the same here too to get feedback/queries in each item. Existing policy defaults suffer from three major faults: #1: the admin-ness problem: use of policy rules like 'is_admin' or hard-coded is-admin checks results in the admin-anywhere-admin-everywhere problem and drastically inhibits true multitenancy since by default customers cannot have admin rights on their own projects or domains #2: insecure custom roles: many policy rules simply use "" as the rule, which means there is no rule: anyone can perform that action. This means creation of a custom role (say, "nova-autoscaler" requires editing every policy file across every service to block users with such a rule from performing actions unrelated to their role #3: related to #2, no support for read-only roles: keystone now has a "reader" role that comes out of the box when keystone is bootstrapped, but it currently has very little value because of the use of empty rules in service policies: users with the "reader" role can still perform write actions on services if the policy rule for such an action is empty. The keystone project has migrated all of its default policies to 1) use oslo.policy's scope_types attribute, which allows the policy engine to understand "system scope" and distinguish between an admin role assignment on a project versus an admin role assignment on the entire system, 2) ensure all rules use one of the default roles (admin, member, and reader) which both ensures support for a read-only role and prevents custom roles from accidental over-permissiveness. Although the problems being solved are slightly different, the keystone team found it was easiest to migrate everything at once. The rest of the OpenStack services can use this migration as a template for securing their own policies. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010287.… http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010290.… [2] https://etherpad.openstack.org/p/ptg-train-xproj-nova-keystone [3] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… -gmann

3 4

[SIGs][meta-sig] Encourage SIG Chairs to join `Meet the project leaders` opportunities in Shanghai
by Rico Lin 31 Oct '19

31 Oct '19

Dear SIG chairs There will be two `Meet the project leaders` event in Shanghai summit. And SIG chairs are definitely part of it. I'm here to encourage you to sign up [1] and join that event so people might get more chances to meet with you. They're scheduled on Monday marketplace mixer (5:30pm-7:00pm) and Wednesday lunch (12:20pm-1:40pm). [1] https://etherpad.openstack.org/p/meet-the-project-leaders -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[openstack-dev][kuryr] Error in creating LB
by VeeraReddy 31 Oct '19

31 Oct '19

Hi, I am trying to install openstack & Kubernetes usingdevstack https://docs.openstack.org/kuryr-kubernetes/latest/installation/devstack/ba… ErrorLog : http://paste.openstack.org/show/785670/ Local.conf : http://paste.openstack.org/show/785671/ Regards, Veera.

1 0

[scientific-sig] OpenStack maintenance planning
by Sebastian Luna Valero 31 Oct '19

31 Oct '19

Hi All, At our Institute we have secured funding to buy a small infrastructure. We have surveyed the computational requirements of researchers and we came to the conclusion that we need to deploy OpenStack on-prem. No one at our Institute has worked with OpenStack before so there is no local expertise. I have been looking around at the available options. Given the complexity of OpenStack and the tight time-frame that we have to get the infrastructure up and running, we would like to go with one of the OpenStack distributions offered by vendors to minimize the time it takes to go into production. Over the initial period, we would need to learn from the vendor how to operate and troubleshoot OpenStack properly, but in the long run we would like to be autonomous. On the other hand, funding in academia is complex and there is no guarantee that we'll be successful in all future funding calls. So in the scenario where we start off with an OpenStack distribution offered by a vendor, and 3 years down the line we run out of budget, can we continue operating/upgrading our OpenStack deployment without issues? Best regards, Sebastian

1 0