April 2019 - openstack-discuss - lists.openstack.org

[tripleo] Nominate Cédric Jeanneret (Tengu) for tripleo-validations core
by Gaël Chamoulaud 04 May '19

04 May '19

Hi TripleO devs, The new Validation Framework is a big step further for the tripleo-validations project. In many ways, it improves the way of detecting & reporting potential issues during a TripleO deployment. As the mastermind of this new framework, Cédric brought a new lease of life to the tripleo-validations project. That's why we would highly benefit from his addition to the core reviewer team. Assuming that there are no objections, we will add Cédric to the core team next week. Thanks, Cédric, for your excellent work! =Gaël

10 10

[Vitrage] add datasource kapacitor for vitrage
by hoanq13＠viettel.com.vn 04 May '19

04 May '19

Hi, In our system, we use monitor by TICK stack (include: Telegraf for collect metric, InfluxDB for storage metric, Chronograf for visualize and Kapacitor alarming), which is popular monitor solution. We hope can integrate vitrage in, so we decide to write kapacitor datasource contribute for vitrage. The work is almost done , you can review in: https://review.opendev.org/653416 So i send this mail hope for more review, ideal,... Appreciate it. also ask: have any step i miss in pipeline of contribute datasource vitrage? like create blueprints, vitrage-spec,vv.. Should i do it?

2 2

[keystone][heat] security_compliance options and auto-created users
by Pavlo Shchelokovskyy 03 May '19

03 May '19

Hi all, I am currently looking at options defined in [security_compliance] section of keystone.conf [0] and trying to understand how enabling those security features may affect other services. The first thing I see is that any project that auto-creates some temporary users may be affected. Of the top of my head I can recall only Heat and Tempest doing this. For Tempest situation is easier as a) tempest can use static credentials instead of dynamic ones so it is possible to craft appropriate users beforehand and b) those users are relatively short-lived (required for limited time). In case of Heat though those users are used for deferred auth (like in autoscaling) which for long lived stacks can happen at arbitrary time in future - which is a problem. Below is breakdown of options/features possible to set and what problems that may pose for Heat and ideas on how to work those around: - disable_user_account_days_inactive - this may pose a problem for deferred auth, and it seems is not possible to override it via user "options". IMO there's a need to add a new user option to Keystone to ignore this setting for given user, and then use it in Heat to create temporary users. - lockout failure options (lockout_failure_attempts, lockout_duration) - can be overridden by user option, but Heat has to set it first. Also the question remains how realistically such problem may arise for an auto-created internal user and whether Heat should set this option at all - password expiry options (password_expires_days, unique_last_password_count, minimum_password_age) - poses a problem for deferred auth, but can be overridden by user option, so Heat should definitely set it IMO for users it creates - change_password_upon_first_use - poses problem for auto-generated users, can be overridden by a user option, but Heat must set it for its generated users - password strength enforcement (password_regex, password_regex_description) - now this is an interesting one. Currently Heat creates passwords for its temporary users with this function [1] falling back to empty password if a resource is not generating one for itself. Depending on regex_password setting in keystone, it may or may not be enough to pass the password strength check. I've looked around and (as expected) generating a random string which satisfies a pre-defined arbitrary regex is quite a non-trivial task, couple of existing Python libraries that can do this note that they support only a limited subset of full regex spec. So it seems that a most simple solution would be to add yet another user option to Keystone to ignore password strength enforcement for this given user, and amend Heat to set this option as well for internal users it creates. We in Heat may also think as to whether it would have any benefit to also set the 'lock_password' user option for the auto-created users which will prohibit such users to change their passwords via API themselves. I'd very like to hear opinion from Keystone community as most solutions I named are 'add new user option to Keystone' :-) [0] https://opendev.org/openstack/keystone/src/branch/master/keystone/conf/secu… [1] https://opendev.org/openstack/heat/src/branch/master/heat/common/password_g… Cheers, - Pavlo -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

4 4

[oslo] Proposing Hervé Beraud for Oslo Core
by Ben Nemec 03 May '19

03 May '19

Hi, Hervé has been working on Oslo for a while now and in that time has shown tremendous growth in his understanding of Oslo and OpenStack. I think he would make a good addition to the general Oslo core team. Existing Oslo team members (+Keystone, Castellan, and anyone else we co-own libraries with) please respond with +1/-1. If there are no objections I'll add him to the ACL next week and we can celebrate in person. :-) Thanks. -Ben

9 9

properly sizing openstack controlplane infrastructure
by Hartwig Hauschild 02 May '19

02 May '19

Hi everyone, A colleague and I have more or less recently been tasked with redesigning my employers openstack-infrastructure and it turned out that starting over will be easier than fixing the existing stack as we've managed to lock ourselves in a corner quite good. The requirements we've got are basically "here's 50 compute-nodes, make sure whatever you're building scales upwards from there". We have the existing pike-stack as a reference but we don't really know how the different services scale up with more compute-nodes to handle. The pike-stack has three servers as control-plane, each of them with 96G of RAM and they don't seem to have too much room left when coordinating 14 compute-nodes. We're thinking about splitting the control-nodes into infrastructure (db/rabbit/memcache) and API. What would I want to look for when sizing those control-nodes? I've not been able to find any references for this at all, just rather nebulous '8G RAM should do' which is around what our rabbit currently inhales. Also: We're currently running Neutron in OVS-DVR-VXLAN-Configuration. Does that properly scale up and above 50+ nodes or should we look into offloading the networking onto something else? I'm aware that the questions may sound a bit funny, but we have to spec out the controlplane-hardware before we can start testing and we'd prefer not to retrofit the servers because we goofed up. Thanks for your time, -- Cheers, Hardy

4 7

kube_cluster_deploy fails
by Pawel Konczalski 02 May '19

02 May '19

Hi, i try to deploy a kubernetes cluster on OpenStack rocky with Magnum. All Heat steps runs fine except for the last one "kube_cluster_deploy": kube_cluster_deploy c3a79e96-87d8-442e-83f1-91d7a1acd896 1 minute Create Failed CREATE aborted (Task create from SoftwareDeployment "kube_cluster_deploy" Stack "kubernetes-cluster9-l4ol4ger3key" [b17bfab3-f46a-477b-921f-4719bfd8df06] Timed out) The cluster contains three control / compute nodes, Octavia is also installed and works fine as far as I can see. Atomic Image: https://dl.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-2018041… The command was: openstack coe cluster template create kubernetes-cluster-template \ --image fedora-atomic-latest \ --external-network public \ --dns-nameserver 8.8.8.8 \ --master-flavor m1.small \ --flavor m1.large \ --coe kubernetes \ --docker-volume-size 10 \ --tls-disabled \ --floating-ip-enabled openstack coe cluster create kubernetes-cluster \ --cluster-template kubernetes-cluster-template \ --master-count 1 \ --node-count 1 \ --timeout 30 \ --keypair mykey Did someone run also into this Problem or know how to fix it? BR Pawel

3 4

[openstack-dev] [neutron] PTG agenda
by Miguel Lavalle 02 May '19

02 May '19

Hi Neutrinos,, I took your proposals for PTG topics and organized them in an agenda. Please look at https://etherpad.openstack.org/p/openstack-networking-train-ptg. Let's have a very productive meeting! Best regards Miguel

2 3

[glance] [ops] Issue sharing an image with another project (something related to get_image_location)
by Massimo Sgaravatto 02 May '19

02 May '19

I have a small Rocky installation where Glance is configured with 2 backends (old images use the 'file' backend while new ones use the rbd backend, which is the default) show_multiple_locations is true but I have these settings in policy.json: # grep _image_location /etc/glance/policy.json "delete_image_location": "role:admin", "get_image_location": "role:admin", "set_image_location": "role:admin", This was done because of: https://wiki.openstack.org/wiki/OSSN/OSSN-0065 If an unpriv user tries to share a private image: $ openstack image add project 3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6 e81df4c0b493439abb8b85bfd4cbe071 403 Forbidden: Not allowed to create members for image 3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6. (HTTP 403) In the log file it looks like that the problem is related to the get_image_location operation: /var/log/glance/api.log:2019-04-29 16:06:54.523 8220 WARNING glance.api.v2.image_members [req-dd93cdc9-767d-4c51-8e5a-edf746c02264 ab573ba3ea014b778193b6922ffffe6d ee1865a76440481cbcff08544c7d580a - default default] Not allowed to create members for image 3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6.: Forbidden: You are not authorized to complete get_image_location action. But actually the sharing operation succeeded: $ glance member-list --image-id 3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6 +--------------------------------------+----------------------------------+---------+ | Image ID | Member ID | Status | +--------------------------------------+----------------------------------+---------+ | 3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6 | e81df4c0b493439abb8b85bfd4cbe071 | pending | +--------------------------------------+----------------------------------+---------+ Cheers, Massimo

2 3

[OpenStack-Ansible][OSA] Team Dinner Denver
by Amy Marrich 01 May '19

01 May '19

We are looking at having our official team dinner Wednesday evening. Please visit this etherpad: https://etherpad.openstack.org/p/osa-team-dinner-plan To add your name and vote on restaurants so I can get a head count and make a reservation. Thanks, Amy (spotz)

2 1

[devstack] Identity URL problem
by Neil Jerram 01 May '19

01 May '19

Does anyone know what causes this problem at [1]: 2019-04-30 16:34:03.137 | +++ functions-common:oscwrap:2346 : command openstack role add admin --user neutron --project service --user-domain Default --project-domain Default 2019-04-30 16:34:03.139 | +++ functions-common:oscwrap:2346 : openstack role add admin --user neutron --project service --user-domain Default --project-domain Default 2019-04-30 16:34:04.331 | Failed to discover available identity versions when contacting http://104.239.175.234/identity. Attempting to parse version from URL. 2019-04-30 16:34:04.331 | Could not find versioned identity endpoints when attempting to authenticate. Please check that your auth_url is correct. Not Found (HTTP 404) [1] http://logs.openstack.org/79/638479/3/check/networking-calico-tempest-dsvm/… I think there are loads of uses of that URL, before where the networking-calico plugin uses it, so I can't see why the plugin's use hits that error. Thanks, Neil

2 3