June 2019 - openstack-discuss - lists.openstack.org

[neutron] Zuul checks fail
by Bernard Cafarelli 17 Jun '19

17 Jun '19

Hi neutrinos, a quick heads-up that currently Zuul will 100% give -1 on your reviews, failing 404 Not Found when trying to download Ubuntu Xenial image. Thanks to Yulong for filling launchpad bug [0] and submitting fix [1]. Once it is merged, we should be back in business [0] https://bugs.launchpad.net/neutron/+bug/1832968 [1] https://review.opendev.org/#/c/665530/ -- Bernard Cafarelli

1 1

[all][qinling] Please check your README files
by Marcin Juszkiewicz 17 Jun '19

17 Jun '19

Train cycle is supposed to be "we really go for Python 3" cycle. Contrary to previous "we do not have to care about Python 3" ones. I am working on switching Kolla images into Python 3 by default [1]. It is a job I would not recommend even to my potential enemies. Misc projects fail into random ways (sent a bunch of patches). 1. https://review.opendev.org/#/c/642375 Quite common issue is related to README files. I know that we have XXI century and UTF-8 is encoding for most of people here. But Python tools are not so advanced so far and loves to explode when see characters outside of US-ASCII encoding. Please check your README files. And move them to US-ASCII if needed. I already fixed few projects [2][3][4][5] but would love to see developers fixing their code too. 2. https://review.opendev.org/644531 3. https://review.opendev.org/644533 4. https://review.opendev.org/644535 5. https://review.opendev.org/644536

5 8

[telemetry] volume_type_id stored instead of volume_type name
by Florian Engelmann 17 Jun '19

17 Jun '19

Hi, some volumes are stored with the volume_type Id instead of the volume_type name: openstack metric resource history --details b5496a42-c766-4267-9248-6149aa9dd483 -c id -c revision_start -c revision_end -c instance_id -c volume_type +--------------------------------------+----------------------------------+----------------------------------+--------------------------------------+--------------------------------------+ | id | revision_start | revision_end | instance_id | volume_type | +--------------------------------------+----------------------------------+----------------------------------+--------------------------------------+--------------------------------------+ | b5496a42-c766-4267-9248-6149aa9dd483 | 2019-05-08T07:21:35.354474+00:00 | 2019-05-21T09:18:32.767426+00:00 | 662998da-c3d1-45c5-9120-2cff6240e3b6 | v-ssd-std | | b5496a42-c766-4267-9248-6149aa9dd483 | 2019-05-21T09:18:32.767426+00:00 | 2019-05-21T09:18:32.845700+00:00 | 662998da-c3d1-45c5-9120-2cff6240e3b6 | v-ssd-std | | b5496a42-c766-4267-9248-6149aa9dd483 | 2019-05-21T09:18:32.845700+00:00 | None | 662998da-c3d1-45c5-9120-2cff6240e3b6 | 8bd7e1b1-3396-49bf-802c-8c31a9444895 | +--------------------------------------+----------------------------------+----------------------------------+--------------------------------------+--------------------------------------+ I was not able to find anything fishy in ceilometer. So I guess it could be some event/notification with a wrong payload? Could anyone please verify this error is not uniq to our (rocky) environment by running: openstack metric resource list --type volume -c id -c volume_type All the best, Florian

2 1

[tripleo][molecule] feedback on testing ansible roles with molecule
by Sorin Sbarnea 17 Jun '19

17 Jun '19

Hi! While we do now have a POC job running molecule with tox for testing one tripleo-common role, I would like to ask for some feedback from running the same test locally, on your dev box. The report generated but openstack-tox-mol job looks like http://logs.openstack.org/36/663336/14/check/openstack-tox-mol/aa7345d/tox/… <http://logs.openstack.org/36/663336/14/check/openstack-tox-mol/aa7345d/tox/…> https://review.opendev.org/#/c/663336/ <https://review.opendev.org/#/c/663336/> Just download it and run: tox -e mol You will either need docker or at least to define DOCKER_HOST=ssh://somehost <ssh://somehost> as an alternative. Please send the feedback back to me or directly on the the review. Over the last days I fixed few minor issues related to differences between user environments and I want to make I improve it as much as possible. Thanks Sorin Sbarnea Tripleo CI

3 3

[nova] Strict isolation of group of hosts for image and flavor, modifying command 'nova-manage placement sync_aggregates'
by Kamde, Vrushali 17 Jun '19

17 Jun '19

Hi, Working on implementation of 'Support filtering of allocation_candidates by forbidden aggregates' spec. Need discussion particularly for point [1] where traits needs to be sync along with aggregates at placement. Master implementation for 'nova-manage placement sync_aggregates' command is to sync the nova host aggregates. Modifying this command to sync trait metadata of aggregate at placement. Below are the aggregate restful APIs which currently supports: 1. 'POST'-- /os-aggregates/{aggregate_id}/action(Add host) getting synced on the placement service 2. 'POST'-- /os-aggregates/{aggregate_id}/action(Remove host) getting synced on the placement service 3. 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) Doesn't get sync on the placement service. 4. 'POST'-- /os-aggregates/{aggregate_id}/action(unset metadata) Doesn't get sync on the placement service. I have added code to sync traits for below APIs and I don't see any issues there: 1. 'POST'-- /os-aggregates/{aggregate_id}/action(Add host) 2. 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) But there is an issue while removing traits for below APIs: 1. 'POST'-- /os-aggregates/{aggregate_id}/action(Remove host) 2. 'POST'-- /os-aggregates/{aggregate_id}/action(unset metadata) Ideally, we should remove traits set in the aggregate metadata from the resource providers associated with the aggregate for above two APIs but it could cause a problem for below scenario:- For example: 1. Create two aggregates 'agg1' and 'agg2' by using: 'POST'-- /os-aggregates(Create aggregate) 2. Associate above aggregates to host 'RP1' by using: 'POST'-- /os-aggregates/{aggregate_id}/action(Add host) 3. Setting metadata (trait:STORAGE_DISK_SSD='required') on the aggregate agg1 by using: 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) 4. Setting metadata (trait:STORAGE_DISK_SSD='required', trait:HW_CPU_X86_SGX='required') on the aggregate agg2 by using: 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) Traits set to 'RP1' are: STORAGE_DISK_SSD HW_CPU_X86_SGX Note: Here trait 'STORAGE_DISK_SSD' is set on both agg1 and agg2. Now, If we remove host 'RP1' from 'agg1' then the trait 'STORAGE_DISK_SSD' set to `RP1` also needs to be removed but since 'RP1' is also assigned to 'agg2', removing 'STORAGE_DISK_SSD' trait from 'RP1' is not correct. I have discussed about syncing traits issues with Eric on IRC [2], he has suggested few approaches as below: - Leave all traits alone. If they need to be removed, it would have to be manually via a separate step. - Support a new option so the caller can dictate whether the operation should remove the traits. (This is all-or-none.) - Define a "namespace" - a trait substring - and remove only traits in that namespace. If I'm not wrong, for last two approaches, we would need to change RestFul APIs. Need your feedback whether traits should be deleted from resource provider or not for below two cases? 1. 'POST'-- /os-aggregates/{aggregate_id}/action(Remove host) 2. 'POST'-- /os-aggregates/{aggregate_id}/action(unset metadata) [1]: https://review.opendev.org/#/c/609960/8/specs/train/approved/placement-req-… [2]: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… Thanks & Regards, Vrushali Kamde Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

5 11

Comparative analysis of openstack and Cloudstack
by Dhairyasheel Ghadge 17 Jun '19

17 Jun '19

Hello all!!! I have been exploring the cloudstack cloud platform while comparing it with the openstack cloud platform. I am a little skeptical about which solution to use as our cloud platform between cloudstack and OpenStack. Following are the difficulties I am facing which comparing these two solutions. 1.) OpenStack has HEAT as the component for orchestration of application VM's deployed and the cloud setup services as well. Is there any orchestration feature in cloudstack which provides an autscaling feature for the application deployed in it? 2.) OpenStack has TROVE for DBaaS which takes care of the entire lifecycle of the database service which includes deployment, configuration, replication, failover, backup, patching, restores. Is there any similar service in cloudstack for providing DBaaS? 3.) Cloudstack documentation says that it has orchestration feature for its applications, but couldn't find any details regarding the same. Also, for big data Hadoop clusters provisioning, SAHARA component is used in OpenStack. What does this sahara feature provides and is it useful for big data applications? This is feature is not there in cloudstack. What is the importance of serverless functionality feature "Qinling" in openstack which is not there in cloudstack Are there any points of Openstack which completely outshines itself from cloudstack? Thankyou Dhairyasheel Ghadge

2 1

getting issues while configuring the Trove
by Saikrishna Ura 17 Jun '19

17 Jun '19

Hi, I installed Openstack in Ubuntu 18.04 by cloning the devstack repository with this url "git clone https://git.openstack.org/openstack-dev/devstack", but i can't able create or access with the trove, I'm getting issues with the installation. Can anyone help on this issue please. If any reference document or any guidance much appreciated. Thanks, Saikrishna U.

3 4

[Keystone] Performance degradation
by Gary Kotton 17 Jun '19

17 Jun '19

Hi, Over the last few weeks we have being doing performance tests on the Stein version and have seen a notable performance degradation. Further investigation showed that Keystone seems to be the bottleneck. An example of this is running a Rally test that creates a keystone tenant with users. We see that in Queens this takes 20 seconds to complete the whole iteration whilst Stein takes 30 seconds. We have done the following tests: 1. Vanilla devstack Queens vs Steins 2. In our Stein version e have swapped out the Keystone Stein container with the Keystone Queens container and the numbers are considerably better too (please note the same keystone configuration is used with regards to processes/threads etc.) Are any folks familiar with what may cause this? Are there any performance improvement suggestions or hints? Thanks Gary

2 4

[nova] Admin user cannot create vm with user's port?
by Lingxian Kong 17 Jun '19

17 Jun '19

Hi Nova team, In Nova, even the admin user cannot specify user's port to create a vm, is that designed intentionally or sounds like a bug? Best regards, Lingxian Kong Catalyst Cloud

3 6

Nova scheduler -- which compute node?
by Ken D'Ambrosio 16 Jun '19

16 Jun '19

Hey, all. First things first: we're running Juno. Yeah, it's ancient, and we've got Queens on-deck, but it's Juno. Anyway, to my question: how can you tell which compute node is *actually getting* the VM request, shy of logging into them and looking? For example, on the Nova node, you can see the nova-scheduler.log file talk about which hosts are weighted how, but it doesn't seem as if it actually comes out and says which host it's trying to give the VM to. Am I missing something? (I'd happily supply log snippets, but I figure this is a fairly general question, and didn't want to paste 1.7 TB of random, possibly-relevant logs.) Thanks! -Ken

2 1