February 2019 - openstack-discuss

[all] [forum] Forum Submissions are open!
by Jimmy McArthur 28 Feb '19

28 Feb '19

Hi Everyone - A quick reminder that we are accepting Forum [1] submissions for the 2019 Open Infrastructure Summit in Denver [2]. Please submit your ideas through the Summit CFP tool [3] through March 8th. Don't forget to put your brainstorming etherpad up on the Denver Forum page [4]. This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1]. If you have questions or concerns, please reach out to speakersupport(a)openstack.org <mailto:speakersupport@openstack.org>. Cheers, Jimmy [1] https://wiki.openstack.org/wiki/Forum [2] https://www.openstack.org/summit/denver-2019/ [3] https://www.openstack.org/summit/denver-2019/call-for-presentations [4] https://wiki.openstack.org/wiki/Forum/Denver2019 ___________________________________________

8 16

[dev][oslo] oslo.cache and dogpile 0.7.0+ cache errors
by Herve Beraud 28 Feb '19

28 Feb '19

Hi, Just a heads up that the latest version of dogpile (0.7.0 onwards) have become incompatible with oslo.cache. This is causing a few issues for jobs. It's a little complex due to functional code and many decorated functions. The error you will see is: *oslo_cache.**tests.test_**cache.CacheRegi**onTest.**test_function_* *key_generator_* *with_kwargs -------**-------**-------**-------**-------**-------**-------* *-------**-------**-------**-------**------* *Captured traceback: ~~~~~~~~~~~~~~~~~~~ b'Traceback (most recent call last):' b' File "/tmp/oslo.**cache/oslo_**cache/tests/**test_cache.**py", line 324, in test_function_**key_generator_* *with_kwargs' b' value=self.**test_value)* *' b' File "/tmp/oslo.**cache/.**tox/py37/**lib/python3.**7/site-* *packages/**testtools/**testcase.* *py", line 485, in assertRaises' b' self.assertThat* *(our_callable, matcher)' b' File "/tmp/oslo.**cache/.**tox/py37/* *lib/python3.**7/site-**packages/**testtools/**testcase.* *py", line 498, in assertThat' b' raise mismatch_error' b'testtools* *.matchers.**_impl.MismatchE**rror: <function CacheRegionTest* *._get_cacheable**_function.**<locals>**.cacheable_**function at 0x7fec3f795400> returned <oslo_cache.**tests.test_**cache.TestProxy**Value object at 0x7fec3f792550>'* The problem appear since we uncap dogpile.cache on oslo.cache: https://github.com/openstack/oslo.cache/commit/62b53099861134859482656dc92d… The following unit test fail since we uncap dogpile => https://github.com/openstack/oslo.cache/blob/master/oslo_cache/tests/test_c… The problem was introduced by: https://gerrit.sqlalchemy.org/#/c/sqlalchemy/dogpile.cache/+/996/ Your main issue on oslo.cache side is that keyword arguments are tranformed in positionnal arguments when we use dogpile.cache.region.cache_on_arguments. I've try to revert the changes introduced by the previous dogpile.cache change and everything works fine on the oslo.cache side when changes was reverted (reverted to revision https://github.com/sqlalchemy/dogpile.cache/blob/2762ada1f5e43075494d91c512… ). The expected behavior is that dogpile.cache.util.function_key_generator raise a ValueError if **kwargs founds, but our kwargs is empty and our `value=self.test_value was` is recognized as a positionnal argument. Our unit test looking for an assertRaise(ValueError) on cachable decorated function when we pass kwargs but it doesn't happen due to empty kwargs. For these reasons we guess that is an dogpile.cache issue and not an oslo.cache issue due to the changes introduced by `decorator` module. The following are related: - https://github.com/openstack/oslo.cache/blob/master/oslo_cache/tests/test_c… : unit test where the problem occure - https://review.openstack.org/#/c/638788/ : possible fix but we don't think that is the right way - https://review.openstack.org/#/c/638732/ : possible remove of the unit test who fail The issue is being tracked in: https://bugs.launchpad.net/oslo.cache/+bug/1817032 If some dogpile expert can take a look and send feedback on this thread you are welcome. Thanks, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

3 6

Issue with ceph and vault
by Wouter van Bommel 28 Feb '19

28 Feb '19

Hi, I currently bumped into a situation in a cloud using both ceph and vault. While adding a new node to the cloud all seemed fine, until I noticed that on one node juju failed with the message: hook failed: "secrets-storage-relation-changed" Upon investigation it turned out that this node had a broken network configuration that was not picket up earlier. The problem was, that the vault instance could not be reached. This was fixed, but I could not un-wedge the error. A juju resolve on the node does not seem to have any effect. Using the debug-log option from juju I do see the following lines that do indicate the problem. INFO:vaultlocker.dmcrypt:LUKS formatting /dev/disk/by-dname/osd1-part1 using UUID:4448f9fa-d291-403e-9826-7318e57cf1a4 Cannot format device /dev/disk/by-dname/osd1-part1 which is still in use. vaultlocker: Command '['cryptsetup', '--batch-mode', '--uuid', '4448f9fa-d291-403e-9826-7318e57cf1a4', '--key-file', '-', 'luksFormat', '/dev/disk/by-dname/osd1-part1']' returned non-zero exit status 5 So the disk is in use. Which looks strange to me, as this machine could never complete the hooks as the vault was unreachable. I would like to get some advice on how to proceed. Regrds, Wouter

2 1

[tc][election] campaign question: team approval criteria
by Doug Hellmann 28 Feb '19

28 Feb '19

One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2]. What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams? What other changes, if any, would you propose to the official team approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet? How would you apply those rule changes to existing teams? [1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html -- Doug

7 12

Re: [placement][TripleO][infra] zuul job dependencies for greater good?
by Bogdan Dobrelya 28 Feb '19

28 Feb '19

I think we can still consider the middle-ground, where only deprecated multinode jobs, which tripleo infra team is in progress of migrating into standalone jobs, could be made depending on unit and pep8 checks? And some basic jobs will keep being depending on nothing. I expanded that idea in WIP topic [0]. Commit messages explain how the ordering was reworked. PS. I'm sorry I missed the submitted stats for zuul projects posted earlier in this topic, I'll take a look into that. [0] https://review.openstack.org/#/q/topic:ci_pipelines+(status:open+OR+status:… > Bogdan Dobrelya <bdobreli at redhat.com> writes: >> On 26.02.2019 17:53, James E. Blair wrote: >>> Bogdan Dobrelya <bdobreli at redhat.com> writes: >>> >>>> I attempted [0] to do that for tripleo-ci, but zuul was (and still >>>> does) complaining for some weird graphs building things :/ >>>> >>>> See also the related topic [1] from the past. >>>> >>>> [0] https://review.openstack.org/#/c/568543 >>>> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/127869.html >>> >>> Thank you for linking to [1]. It's worth re-reading. Especially the >>> part at the end. >>> >>> -Jim >>> >> > > Yes, the part at the end is the best indeed. > I'd amend the time priorities graph though like that: > > CPU-time < a developer time < developers time > > That means burning some CPU and nodes in a pool for a waste might > benefit a developer, but saving some CPU and nodes in a pool would > benefit *developers* in many projects as they'd get the jobs results off > the waiting check queues faster :) -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 2

[ceilometer] radosgw pollster
by Florian Engelmann 28 Feb '19

28 Feb '19

Hi, I failed to poll any usage data from our radosgw. I get 2019-02-22 17:23:57.461 24 INFO ceilometer.polling.manager [-] Polling pollster radosgw.containers.objects in the context of radosgw_300s_pollsters 2019-02-22 17:23:57.462 24 ERROR ceilometer.polling.manager [-] Prevent pollster radosgw.containers.objects from polling [<Project description=, domain_id=xx9d9975088a4d93922e1d73c7217b3b, enabled=True, [...] id=xx90a9b1d4be4d75b4bd08ab8107e4ff, is_domain=False, links={u'self': u'http://keystone-admin.service.xxxxxxx:35357/v3/projects on source radosgw_300s_pollsters anymore!: PollsterPermanentError Configurations like: cat polling.yaml --- sources: - name: radosgw_300s_pollsters interval: 300 meters: - radosgw.usage - radosgw.objects - radosgw.objects.size - radosgw.objects.containers - radosgw.containers.objects - radosgw.containers.objects.size Also tried radosgw.api.requests instead of radowsgw.usage. ceilometer.conf [...] [service_types] radosgw = object-store [rgw_admin_credentials] access_key = xxxxx0Z0xxxxxxxxxxxx secret_key = xxxxxxxxxxxxlRExxcPxxxxxxoNxxxxxxOxxxx [rgw_client] implicit_tenants = true Endpoints: | xxxxxxx | region | swift | object-store | True | admin | http://rgw.service.internalxxx/swift/v1/AUTH_%(tenant_id)s | | xxxxxxx | region | swift | object-store | True | internal | http://rgw.service.internalxxx/swift/v1/AUTH_%(tenant_id)s | | xxxxxxx | region | swift | object-store | True | public | https://s3.somedomain.com/swift/v1/AUTH_%(tenant_id)s | Ceilometer user: { "user_id": "ceilometer", "display_name": "ceilometer", "email": "", "suspended": 0, "max_buckets": 1000, "auid": 0, "subusers": [], "keys": [ { "user": "ceilometer", "access_key": "xxxxxxxxxxxxxxxxxx", "secret_key": "xxxxxxxxxxxxxxxxxxxxxxxxx" } ], "swift_keys": [], "caps": [ { "type": "buckets", "perm": "read" }, { "type": "metadata", "perm": "read" }, { "type": "usage", "perm": "read" }, { "type": "users", "perm": "read" } ], "op_mask": "read, write, delete", "default_placement": "", "placement_tags": [], "bucket_quota": { "enabled": false, "check_on_raw": false, "max_size": -1, "max_size_kb": 0, "max_objects": -1 }, "user_quota": { "enabled": false, "check_on_raw": false, "max_size": -1, "max_size_kb": 0, "max_objects": -1 }, "temp_url_keys": [], "type": "rgw" } radosgw config: [client.rgw.xxxxxxxxxxx] host = somehost rgw frontends = "civetweb port=7480 num_threads=512" rgw num rados handles = 8 rgw thread pool size = 512 rgw cache enabled = true rgw dns name = s3.xxxxxx.xxx rgw enable usage log = true rgw usage log tick interval = 30 rgw realm = public rgw zonegroup = xxx rgw zone = xxxxx rgw resolve cname = False rgw usage log flush threshold = 1024 rgw usage max user shards = 1 rgw usage max shards = 32 rgw_keystone_url = https://keystone.xxxxxxxxxxxxx rgw_keystone_admin_domain = default rgw_keystone_admin_project = service rgw_keystone_admin_user = swift rgw_keystone_admin_password = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx rgw_keystone_accepted_roles = member,_member_,admin rgw_keystone_accepted_admin_roles = admin rgw_keystone_api_version = 3 rgw_keystone_verify_ssl = false rgw_keystone_implicit_tenants = true rgw_keystone_admin_tenant = default rgw_keystone_revocation_interval = 0 rgw_keystone_token_cache_size = 0 rgw_s3_auth_use_keystone = true rgw_max_attr_size = 1024 rgw_max_attrs_num_in_req = 32 rgw_max_attr_name_len = 64 rgw_swift_account_in_url = true rgw_swift_versioning_enabled = true rgw_enable_apis = s3,swift,swift_auth,admin rgw_swift_enforce_content_length = true Any idea whats going on? All the best, Florian

3 7

[nova][dev] Any VMware resource pool and shares kind of feature available in openstack nova?
by Sanjay K 28 Feb '19

28 Feb '19

Hi Matt, I will define/derive priority based on the which sub network the VM belongs to - mostly Production or Development. From this, the Prod VMs will have higher resource allocation criteria than other normal VMs and these can be calculated at runtime when a VM is also rebooted like how VMware resource pools and shares features work. I appreciate any other suggestions. thanks and regards,

4 3

[Openstack-sigs] [publiccloud-wg] Late reminder weekly meeting Public Cloud WG
by Tobias Rydberg 28 Feb '19

28 Feb '19

Hi everyone, Time for a new meeting for PCWG - today (28th) 1400 UTC in #openstack-publiccloud! Agenda found below and at https://etherpad.openstack.org/p/publiccloud-wg Agenda 1. Train goal: Deletion of resources 2. Summit Denver forum topics 3. Followup goals Sorry for the late reminder! Talk to you later today! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

[heat] keystone endpoint configuration
by Jonathan Rosser 27 Feb '19

27 Feb '19

In openstack-ansible we are trying to help a number of our end users with their heat deployments, some of them in conjunction with magnum. There is some uncertainty with how the following heat.conf sections should be configured: [clients_keystone] auth_uri = ... [keystone_authtoken] www_authenticate_uri = ... It does not appear to be possible to define a set of internal or external keystone endpoints in heat.conf which allow the following: * The orchestration panels being functional in horizon * Deployers isolating internal openstack from external networks * Deployers using self signed/company cert on the external endpoint * Magnum deployments completing * Heat delivering an external endpoint at [1] * Heat delivering an external endpoint at [2] There are a number of related bugs: https://bugs.launchpad.net/openstack-ansible/+bug/1814909 https://bugs.launchpad.net/openstack-ansible/+bug/1811086 https://storyboard.openstack.org/#!/story/2004808 https://storyboard.openstack.org/#!/story/2004524 Any help we could get from the heat team to try to understand the root cause of these issues would be really helpful. Jon. [1] https://github.com/openstack/heat/blob/master/heat/engine/resources/server_… [2] https://github.com/openstack/heat/blob/master/heat/engine/resources/signal_…

5 7

[kolla] Proposing Michal Nasiadka to the core team
by Eduardo Gonzalez 27 Feb '19

27 Feb '19

Hi, is my pleasure to propose Michal Nasiadka for the core team in kolla-ansible. Michal has been active reviewer in the last relases ( https://www.stackalytics.com/?module=kolla-group&user_id=mnasiadka) has been keeping an eye on the bugs and being active help on IRC. He has also made efforts in community interactions in Rocky and Stein releases, including PTG attendance. His main interest is NFV and Edge clouds and brings valuable couple of years experience as OpenStack/Kolla operator with good knowledge of Kolla code base. Planning to work on extending Kolla CI scenarios, Edge use cases and improving NFV-related functions ease of deployment. Consider this email as my +1 vote. Vote ends in 7 days (22 feb 2019) Regards

6 6