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

[openstack-dev] [neutron] Cancelling Neutron Drivers meeting
by Miguel Lavalle 28 Jun '19

28 Jun '19

Dear Neutrinos, Next week, the 4th of July Holiday (Independence Day) will be observed in the USA. Since several members of the drivers team live in that country and will enjoy a long weekend, we are cancelling the meeting on the 5th. We will resume our meeting normally on the 12th. Best regards Miguel

1 0

[nova] Last chance to weigh in on nova adopting the SDK for inter-service comms
by Matt Riedemann 28 Jun '19

28 Jun '19

John and I are +2 and Eric is +1 (would be +2 if not involved in the effort) on the nova spec [1] to adopt the openstacksdk for nova communicating with other services rather than the python-*clients. There are several motivations within the spec itself and in review comments for doing this, but since it's a major change to nova across the board I want to make sure other cores and contributors are aware and at least not against this before it's approved. I think a reasonable timeline for waiting to approve is until EOD July 2 (next week) since that's our third and final spec review sprint. [1] https://review.opendev.org/#/c/662881/ -- Thanks, Matt

1 0

[infra] Stepping down as infra-root
by Paul Belanger 28 Jun '19

28 Jun '19

Greetings! 10 months ago my role at Red Hat changed, which saw my day to day job move away from OpenStack, specifically the Infrastructure team. Since then, I've be contributing to OpenStack in my spare time however it isn't going as well I as would like. Unfortunately, there is never enough time in the day to do everything and as a result I believe it is best for me to step day, and remove myself as infra-root: https://review.opendev.org/668192 In the 7 years I've been contributing to the infra team, I've learned a great many things (and still learning). Thank you to all the awesome humans, past and present, for making my day to day much better. To the community, I do ask if you are at all interested in how the infrastructure works / operates, reach out to the #openstack-infra channel and get involved. I refer you to the help wanted list: https://governance.openstack.org/tc/reference/help-most-needed.html#communi… Paul

2 1

https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/ds_util.py
by Keith Berger 28 Jun '19

28 Jun '19

Gary, I hope you are doing well. I was trying to understand the logic in this code when using datastore_regex. It seems even if you set that parameter and it matches some N datastores, the "free capacity " being returned by nova-compute is only from a single/best datastore. def get_available_datastores(session, cluster=None, datastore_regex=None): """Get the datastore list and choose the first local storage.""" ds = session._call_method(vutil, "get_object_property", cluster, "datastore") ... ... if _is_datastore_valid(propdict, datastore_regex, allowed_ds_types): new_ds = ds_obj.Datastore( ref=obj_content.obj, name=propdict['summary.name'], capacity=propdict['summary.capacity'], freespace=propdict['summary.freeSpace']) # favor datastores with more free space if (best_match is None or new_ds.freespace > best_match.freespace): best_match = new_ds return best_match The issue we are seeing is a customer has for example 5 x 10 GB data stores (DS1,..DS5.) For whatever reason , DS1 was filled more fully and once it hit close to 100% no new instances could launch as the were blocked by the Nova DiskFilter. I know we can use the disk_allocation to "fool" this but why is not using to total cumulative storage as opposed to the one with most free or first one. I am wondering if there is some configuration issue. If it is supposed to use best_match, should that dynamically change among the matched regex Datastore to the one with most free space? Could it be it is somehow skipping the "best_match" and always using " first local storage" I appreciate any suggestions or comments you have. Keith -- Keith Berger Master Software Engineer SUSE (P)+1 470.237.2012 (M)+1 404.664.9610 keith.berger(a)suse.com

1 0

[kolla] How can I change package version when building the image?
by Eddie Yen 28 Jun '19

28 Jun '19

Hi, I'm using stable/rocky from git now, but I want to build the prometheus images with latest version since there're few exporters that too previous that can't use most Grafana dashboards in default. I already know I have to edit templates in kolla-ansible since the newer exporters has using the different launch commands. But Idk how to set the version because the document didn't say how to override the Dockerfile. Is that OK to change package version inside Dockerfile? Many thanks, Eddie.

3 4

performance issue with opendev gitea interface.
by Sean Mooney 27 Jun '19

27 Jun '19

i have started this as a separate thread form the Github organization management but it has been in the back of my mind as we are considering not syncing to gitub going forward. for larger project like nova https://opendev.org/openstack/nova preforms quite poorly in both firefox and chome i am seeing ~ 15second before the first response form opendev.org for nova. os-vif or other smaller projects seem to respond ok but for nova it makes navigating the code or liking code to other via opendev quite hard. i brought this up on the infra irc a few weeks ago and asked if gitea had any kind of caching and while the initial response was "we do not believe so". before archiving or stopping syncing to github i was wondering if we could explore options to improve the performace. if opendev.org is not currently fronted by a cdn perhaps that would help. Similarly looking at https://docs.gitea.io/en-us/config-cheat-sheet/ it may be possible to either change the cache or database parameters to improve performance. I really don't know how gitea has been deployed but at present the web interface is not usable in nova in a responsive manner so i have continued to use github when linking code to others but it would be nice to be able to use opendev instead. regards sean.

4 3

[sig][api] API-SIG office hours cancelled for 4 July
by Michael McCune 27 Jun '19

27 Jun '19

due the holiday in the united states and travel by our other members, the api-sig will not hold office hours next thursday, 4 july. thank you =) peace o/

1 0

[security sig] Weekly Newsletter June 27th & July 4th Meeting Canceled
by Gage Hugo 27 Jun '19

27 Jun '19

Just a heads up, but since next Thursday is the 4th of July, we will be canceling next week's Security SIG meeting. Have a safe holiday everyone! #Week of: 27 June 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 - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-06-27-1… - Slow week, discussed the TC approving the Image Encryption pop-up team & TPM passthrough - Next week's meeting will be canceled due to July 4th 🎆 ## News - The TC approved adding "Image Encryption" as a pop-up team - https://review.opendev.org/#/c/661983/ - https://governance.openstack.org/tc/reference/popup-teams.html#image-encryp… - Physical TPM passthrough PoC - https://review.opendev.org/#/c/667926/ - spec - https://review.opendev.org/#/c/667928/ # VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - No new public security bugs this week

1 0

[sahara] Cancelling Sahara meeting July 4
by Jeremy Freudberg 27 Jun '19

27 Jun '19

Hi all, There will be no Sahara meeting this upcoming Thursday, July 4. Holler if you need anything. Thanks, Jeremy

1 0

Re: [nova] Questions on Force refresh instance info_cache during heal
by Matt Riedemann 27 Jun '19

27 Jun '19

On 6/26/2019 4:39 AM, 胡丽娜 wrote: > Dear Matt Riedemann : > I am quiet interested in your recently published > patch https://review.opendev.org/#/c/591607/ , there is a question i > met ，If we spawn VM with port id and then update db , set > network_info='[]' , Afert periodic task_heal_instance_info_cache , > Preserve On Delete turn into False , in face ,it's corret value is True . > Steps to reproduce: > 1.Spawn vm with port id : nova boot --flavor xx --nic port-id --image xx > vm_name > 2.View the value of Preserve On Delete , it'value is True > 3.Update the DB row ,drop interface_list > 4.View the value of Preserve On Delete , it turns into False > Have you ever had this question ? Look forward to your reply ! > Best wishes ! > > 胡丽娜 BC-EC > 中国移动苏州研发中心云计算产品部 > 中移（苏州）软件技术有限公司 > 苏州高新区科技城昆仑山路58号中移软件园 +openstack-discuss mailing list The problem in this case is that nova relies on the network info cache to determine which ports were created by nova and which were pre-existing and provided by the user, either during server create or attached to the server after it was created. When building the network info model we determine the pre-existing port IDs here [1] and then pass that to _build_vif_model here [2]. We then determine the preserve_on_delete value if the port ID is in that pre-existing ports set [3]. What we should probably be doing is if we have lost the cache is always set preserve_on_delete=True since we don't have the cache information to know if we should delete the port when the server is deleted, and it could be an SR-IOV port or something that the user does not want deleted. The worst case in this scenario is the server is deleted and some ports are unbound and left hanging around that the user has to manually cleanup but that's arguably better than deleting something they didn't want to be deleted. I used some similar logic in this related patch [4]. If people agree with this (being conservative when we've lost the cache), then please report a bug and we can make the change (it should be pretty simple). [1] https://review.opendev.org/#/c/591607/25/nova/network/neutronv2/api.py@2826 [2] https://review.opendev.org/#/c/591607/25/nova/network/neutronv2/api.py@2906 [3] https://review.opendev.org/#/c/591607/25/nova/network/neutronv2/api.py@2764 [4] https://review.opendev.org/#/c/640516/ -- Thanks, Matt

1 1