August 2021 - openstack-discuss - lists.openstack.org

Tenant vlan Network Issue
by Karera Tony 09 Sep '21

09 Sep '21

Hello Team, Whenever I create an internal network with type vlan. The Instances don't get IPs but for external Network it's fine. Below is the etc/kolla/config/neutron/ml2_conf.ini file [ml2] type_drivers = flat,vlan,vxlan tenant_network_types = vlan,flat mechanism_drivers = openvswitch,l2population [ml2_type_vlan] network_vlan_ranges = physnet1 [ml2_type_flat] flat_networks = physnet1 Is there something I need to change or I need to configure the interface differently Regards Tony Karera

4 12

[keystone] Weekly meetings
by Douglas Mendizabal 07 Sep '21

07 Sep '21

Hi All, I'm helping the Keystone team get the weekly meetings back on track. [1] I'd like to propose a change to the meeting time slot from Tuesday at 1700 UTC to Tuesday at 1500 UTC to make it a little earlier for our contributors in EMEA. I'll be out next week, so I won't be available to chair the meeting, but I should be back the following week for the August 31 meeting. If there are no objections to this time change, I'll go ahead and propose a change to the meetings repo. Thanks, - Douglas Mendizábal (redrobot) [1] https://meetings.opendev.org/#Keystone_Team_Meeting

1 1

Changing Magnum Heat template to create node network with vxlan instead of vlan
by Karera Tony 07 Sep '21

07 Sep '21

Hello Team, I was able to deploy Openstack with Magnum and Zun enabled. Unfortunately, When I create a cluster, Heat configure the fix/_network for the nodes with Vlan and the nodes fail to get IPs. I was wondering if it is possible to trick the heat templates to create vxlan network instead of vlan. Regards Tony Karera

3 7

[nova][placement] Xena release
by Balazs Gibizer 06 Sep '21

06 Sep '21

Hi, We are getting close to the Xena release. So I created a tracking etherpad[1] with the schedule and TODOs. One thing that I want to highlight is that we will hit Feature Freeze on 3rd of September. As the timeframe between FF and RC1 is short I'm not plannig with FFEs. Patches that are approved before 3rd of Sept EOB can be rechecked or rebased if needed and then re-approved. If you have a patch that is really close but not approved before the deadline, and you think there are two cores that willing to review it before RC1, then please send a mail to the ML with [nova][FFE] subject prefix not later than 7th of Sept EOB. Cheers, gibi [1] https://etherpad.opendev.org/p/nova-xena-rc-potential

1 1

[cinder] discuss nas_secure options and root_squash (prohibiting root access to share)
by Stefan Hoffmann 06 Sep '21

06 Sep '21

Hi cinder team, like discussed in the last meeting, I prepared a list [1] of combinations of the nas_secure options and when to use them. If one want to prohibit root access to NFS share, only setting nas_secure_file_operations and nas_secure_file_permissions to true is a useful option, I think. (Option 4) But also the nas_secure_file_operations is not useful to determine if _qemu_img_info and fs access check at _connect_device should be done with root user or cinder user. So I will update the change [2] like proposed in the etherpad. Feel free to add other use cases and hints for the options to [1] and discuss about the proposed change. Regards Stefan [1] https://etherpad.opendev.org/p/gSotXYAZ3JfJE8FEpMpS [2] https://review.opendev.org/c/openstack/cinder/+/802882 Initial Bug: https://bugs.launchpad.net/cinder/+bug/1938196?comments=all

1 1

[kolla-ansible] Running Docker Swarm with Kuryr networking
by Paolo Celati 02 Sep '21

02 Sep '21

Hi, long story short I have a 3 node Openstack cluster that I manage with kolla-ansible, and I'd like to run Docker Swarm on that as well. I am aware Magnum exists, but I'd first like to get my head around this simpler case. Seeing as I'd like to connect Docker containers from swarm compose files to Neutron networks I'm trying to set up Kuryr together with a swarm configuration. However the documentation is a little scarce <https://docs.openstack.org/kolla-ansible/latest/reference/containers/kuryr-…> and I'd prefer running everything on these three hosts, including etcd. If I follow the guide and pass --cluster-store and --cluster-advertise arguments to dockerd then I can't run Docker in Swarm mode because I get an error saying Swarm is incompatible with those options, and at the same time it's not clear from documentation how you are expected to do Kuryr+Swarm. I did initialise the Swarm cluster before trying to add Kuryr, so I don't know if perhaps doing this the other way works? Do you have ideas or advice with this scenario? If worst comes to worst I can set up an external etcd cluster on a separate non-Openstack cluster but I'd rather avoid that. Thanks in advance, Paolo

4 9

[nova][cinder][barbican] storing secrets in service project
by Pavlo Shchelokovskyy 02 Sep '21

02 Sep '21

Hi all, When Barbican is involved, and services like Nova and Cinder create secrets behind the scenes themselves, this results in problems deleting or otherwise managing some resources by cloud admins. For example as described in https://bugs.launchpad.net/cinder/+bug/1775372, admin can not delete an encrypted volume created by another user, and needs to resort to adding herself to the project first with appropriate roles. This stems IMO from the difference in default resource access policies between Barbican and other services that consume it. For example, while in Nova or Cinder, cloud admin by default can delete servers or volumes in other projects, in Barbican by default only secret creator or admin "in the same project" can delete a secret. I came up with at least 3 solutions (already mentioned in the issue above) but would like to discuss their validity, pros and cons, and especially how they affect the security model and the use cases that this Nova-Cinder-Barbican integration aims to solve. 1. Just ignore failure to delete a secret and log appropriate warning that a secret may be left orphaned. Obviously not the best solution, but rather simple one, also will protect from cases when for whatever reason a secret will be deleted from Barbican directly (e.g. by mistake), rendering volume undeletable for anyone. 2. Change default barbican policies to allow secret deletion for cloud admin (system scope?). Naturally has implications for the Barbican model for resources access, so may be not that appropriate. 3. Store the secrets in the service project instead of user's. Currently those secrets are generated by Nova or Cinder themselves, and user quite probably is not even aware that there was something created in Barbican on her behalf. The user also has no option to pass her own secrets to any of the involved API calls, so this is something happening completely behind the scenes. So do we really need to store these secrets in the user's project? Wouldn't it be better to store them in the service project, have the same service user defined in Nova and Cinder, so it can operate and access those secrets regardless of who manages the resource which depends on access to this secret? This also may solve the problem of encrypted local instance images in Nova, where upon host restart, Nova is not able to bring those instances up because it lacks the context capable of accessing those secrets. I think the third option is the best one, but I may be missing the actual use case meant behind this feature. Is it "keep the data encrypted at rest and in transit" or more strictly "encrypt data of different users with different keys and limit access to those keys" (for the case of breach etc) ? In the first case it seems storing all the auto-generated secrets in a service project would suffice... Please help me understand the best approach to take. Best regards, Pavlo.

4 4

[tc][all]Please help to identify common pain points & video meeting scheduled next week
by Rico Lin 02 Sep '21

02 Sep '21

Dear all First, I thank Kendall and everyone who help with the Pain point elimination etherpad [1]. Two paths we plan to work on or would like to see how we can push it forward: 1. To identify common pain points from OpenStack. And see if we can target them in the following cycles. 2. To see if we can have a community-wide goal to encourage project teams to pick up their own pain point in the following cycles. *This ML is focused on the first path; To identify common pain points.* So I would like to encourage all to help to identify common pain points from it and also help put your feedbacks on the etherpad [1]. To identify common pain points, you can help to leave comments to pain points that you feel it is not an issue for a single project team but for a larger scope. We kind of recognized rabbitmq (or said RPC backend) might be one of the common pain points from that etherpad. And we wish to learn more from all of you. And we need operators' feedback mostly. Also, *we plan to put `identify common pain points` on schedule for the TC meeting next week (which is a video meeting on google meet). If you're interested, please help with etherpad, and join the TC meeting [2] next week.* [1] https://etherpad.opendev.org/p/pain-point-elimination [2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee *Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

1 1

[magnum] [kolla-ansible] [kayobe] [Victoria]
by Tony Pearce 02 Sep '21

02 Sep '21

Testing out Kubernetes with Magnum project, deployed via kayobe on Victoria we have deployed an auto scaling cluster and have run into a problem and I'm not sure how to proceed. I understand that the cluster tried to scale up but the openstack project did not have enough CPU resources to accommodate it (error= Quota exceeded for cores: Requested 4, but already used 20 of 20 cores). So the situation is that the cluster shows "healthy" and "UPDATE_FAILED" but also kubectl commands are failing [1]. What is required to return the cluster back to a working status at this point? I have tried: - cluster resize to reduce number of workers - cluster resize to increase number of workers after increasing project quota - cluster resize and maintaining the same number of workers When trying any of the above, horizon shows an immediate error "Unable to resize given cluster" but magnum logs and heat logs do not show any log update at all at that time. - using "check stack" and resume stack in the stack horizon menu gives this error [2] Investigating the kubectl issue, it was noted that some services had failed on the master node [3]. Manual start as well as reboot the node did not bring up the services. Unfortunately I dont have ssh access to the master and no further information has been forthcoming with regards to logs for those service failures so I am unable to provide anything around that here. I found this link [4] so I decided to delete the master node then run "check" cluster again but the check cluster just fails in the same way except this time it fails saying that it cannot find the master [5] while the previous error was that it could not find a node. Ideally I would prefer to recover the cluster - whether this is still possible I am unsure. I can probably recreate this scenario again. What steps should be performed in this case to restore the cluster? [1] kubectl get no Error from server (Timeout): the server was unable to return a response in the time allotted, but may still be processing the request (get nodes) [2] Resource CHECK failed: ["['NotFound: resources[4].resources.kube-minion: Instance None could not be found. (HTTP 404) (Request-ID: req-6069ff6a-9eb6-4bce-bb25-4ef001ebc428)']. 'CHECK' not fully supported (see resources)"] [3] [systemd] Failed Units: 3 etcd.service heat-container-agent.service logrotate.service [4] https://bugzilla.redhat.com/show_bug.cgi?id=1459854 [5] ["['NotFound: resources.kube_masters.resources[0].resources.kube-master: Instance c6185e8e-1a98-4925-959b-0a56210b8c9e could not be found. (HTTP 404) (Request-ID: req-bdfcc853-7dbb-4022-9208-68b1ab31008a)']. 'CHECK' not fully supported (see resources)"]. Kind regards, Tony Pearce

3 6

[all][tc] Technical Committee next weekly meeting on Sept 2nd at 1500 UTC
by Ghanshyam Mann 02 Sep '21

02 Sep '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for Sept 2nd at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Sept 1st, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

2 2