November 2019 - openstack-discuss

[nova][api]
by Surya Seetharaman 28 Nov '19

28 Nov '19

Hello everyone, We came across this bug [1] in nova recently and wanted to know what people think is the best (relatively) way to fix this. In the past, the project id validation was added as a best effort to prevent users from being able to enter random values into the database. When this validation is used from the os flavor set/unset admin apis [2], there are chances that keystone returns a 403 which gets silently ignored by nova [3] allowing the user to enter the provided project_id/name without validation or warning or remove an existing flavor-project mapping. There were a couple of options discussed on IRC [4] to fix this behaviour out of which the practically reasonable ones are: 1) close the bug as invalid - tweak your config (we could add docs, idk if that would be found or help) to do what you need to avoid the 403 from keystone 2) change the 403 case as an error and raise it back to the compute api caller - maybe enough time has passed to not worry about backward compat with the old non-validating behavior Option 2 seems better than option 1 for most of us, however what we cannot agree upon is if this change should be accompanied by a microversion bump or not. [1] https://bugs.launchpad.net/nova/+bug/1854053 [2] https://github.com/openstack/nova/blob/fd67f69cfdaf04620f2e8a5f1fbf57370969… [3] https://github.com/openstack/nova/blob/d621914442855ce67ce0b99003f7e69e8ee5… [4] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… Cheers, Surya.

5 9

[Tacker] [Mistral] [Network Service] Regarding parameters to Network Service
by Nehal Bansal 28 Nov '19

28 Nov '19

Hi, Is there a way to pass parameters from Network Service Descriptor to the VNF Descriptor using a parameter file? Kindly advise as it would be of great help. Thank you. Regards, Nehal

1 0

[nova] There is no screen for UEFI instance from console display
by yu.chengde＠99cloud.net 28 Nov '19

28 Nov '19

Hi. After launch an UEFI mode instance in OpenStack, the console screen show the message “Guest has no initialized the displayed (yet) " Engage your help, many thanks Base on ubuntu cloud image, listed as below https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64… <https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64…>

2 1

[nova][neutron][cyborg] Bandwidth (and accel) providers are broken if CONF.host is set
by Eric Fried 28 Nov '19

28 Nov '19

Hi all. Sean mentioned a "downstream bug" in IRC today [1], which we discussed a little bit, but without gibi; and then Matt and I discussed it more later [2], but without gibi *or* Sean. Since I don't know if there's a bug report I can comment on, I wanted to summarize here for now so I don't forget. The Problem =========== Neutron needs to know the compute node resource provider on which to hang the child providers for QoS bandwidth. Today it assumes CONF.host is the name of that provider. That's wrong. The name of the provider is `hypervisor_hostname`, which for libvirt [3] happens to match the *default* value of CONF.host [4]. Per the bug Sean describes, if you override CONF.host, neutron won't find the compute node provider, and things break. The problem will be the same for any non-nova wishing to discover the compute node RP -- e.g. cyborg for purposes of creating child providers for accelerators. The Right Solution ================== Neutron (and any $service) should look up the compute node provider by its UUID. That's returned by the /os-hypervisors APIs after microversion 2.53, e.g. [5], but, Catch-22, you can currently only filter those results on hypervisor_hostname. So you would have to e.g. GET /os-hypervisors/detail and then walk the list looking for service.host matching CONF.host. That's way heavy for your CERNs. So the proposal moving forward is to add (in a new microversion) a ?service_host=XXX qparam to those APIs to let you filter down to just the one entry for your CONF.host. The UUID of that entry will also be the UUID of the compute node resource provider. (At that point you don't even need to ask Placement for that provider; you can just use that UUID directly in the APIs that create the child providers. Yay, you got your extra API call back.) Now, that's not backportable, and this problem exists in stable releases (at least those that support QoS bandwidth). So we should totally do it, but we also need... The Backportable Solution ========================= Neutron should use `gethostname()` rather than CONF.host to discover the compute node resource provider. I don't consider this a viable permanent solution because it is tightly coupled to knowing that hypervisor_hostname == `gethostname()`, which happens to be true for libvirt, but not necessarily for other drivers. We can get away with it for stable because we happen to know that we're only supporting QoS bandwidth via Placement for libvirt. Upgrade Concerns ================ Matt and I didn't nail down whether neutron and compute are allowed to be at different versions on a given host, or what those are allowed to be. But things should be sane if neutron (or any $service) logics like this in >=ussuri: if new_nova_microversion_available: do_the_os_hypervisors_thing() elif using_new_non_libvirt_feature: raise YouCantDoThisWithOldNova() else: do_the_gethostname_thing() Action Summary ============== If the above sounds reasonable, it would entail the following actions: - Neutron(/Cyborg?): backportable patch to s/CONF.host/socket.gethostname()/ - Nova: GET /os-hypervisors*?service_host=X in a new microversion. - Neutron/Cyborg: master-only patch to do the logic described in `Upgrade Concerns`_ (though for now without the `elif` branch). Thanks, efried [1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… [2] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… [3] https://opendev.org/openstack/nova/src/commit/1cd5563f2dd2b218db2422397c8aa… [4] https://opendev.org/openstack/nova/src/commit/1cd5563f2dd2b218db2422397c8aa… [5] https://docs.openstack.org/api-ref/compute/?expanded=list-hypervisors-detai…

6 19

Re: [lists.openstack.org代发][nova][ptg] Support re-configure deleted_on_termination in server
by Brin Zhang(张百林) 28 Nov '19

28 Nov '19

Hi Sylvain, Matthew: https://review.opendev.org/#/c/693828/ Here is the PoC code, please review this change, thanks. Sylvain Bauza [mailto:sbauza@redhat.com] Items: [lists.openstack.org代发][nova][ptg] Support re-configure deleted_on_termination in server Spec is https://review.opendev.org/#/c/580336/ Most people seem to think this makes sense but realize there are already other ways to do this (snapshot) and therefore it's not totally necessary. The agreement in the room was to post the code up for the change, as this will help sell people on it if it's trivial enough and document the use case (i.e. are there scenarios where this would make life 10x easier?)

1 0

[kolla] kolla-ceph future
by Michał Nasiadka 28 Nov '19

28 Nov '19

Hello, Ceph deployment functionality in Kolla-Ansible has been deprecated in Train (https://review.opendev.org/#/c/669214/1). Given the fact that Ceph deployment was (and is) important functionality in Kolla-Ansible - I’d like to propose following steps: 1) Improve external Ceph functionality in Kolla-Ansible (configurable keyrings, users, improved documentation) - in progress now 2) Replace current kolla-ceph CI jobs with an equivalent using ceph-ansible (and possibly ceph orchestrator after Octopus is out around March 2020) 3) Remove kolla-ceph functionality in Ussuri release from Kolla-Ansible code base - or (if there are volunteers) extract it as a separate repository with a separate set of maintainers/core team. 4) (OPTIONAL) Find a volunteer to work on ceph-ansible/ceph-orchestrator existing deployment takeover functionality for ceph-kolla (current core team has no spare cycles to work on that) Essentially this mail is a call for volunteers for 3) - if there is somebody that is interested in picking up the code and maintaining it - please speak up. If there are none - we will start preparing for removing the code in 2020. Thank you for your understanding in this not easy decision. Kind regards, Michal Nasiadka

1 0

[olso][pbr][i18n] Using setup.cfg [files] data_files to install localization files
by info＠dantalion.nl 28 Nov '19

28 Nov '19

Hello everyone :), I was wondering what the preferred method to install localization files is. I can think of some probably solutions such as: 1: Including the locale files as part of a package for the target systems package manager (pacman, yum, apt, etc). 2: adding the locale files to the [files] directive in setup.cfg: I hope someone can answer my question. Kind regards, Corne Lukken

3 5

Re: [keystone][nova][barbican][neutron][cinder][tc][policy] Proposal for policy popup team⁩
by yumeng bao 28 Nov '19

28 Nov '19

>> Please nominate Yumeng Bao (yumeng_bao(a)yahoo.com) as the liaison with >> Cyborg team. She will contribute the spec. We have informed Howard of >> this. > Thanks Sundar, I have replaced Howard with Yumeng as the liaison for cyborg. > (Side note - the wiki can be edited by anyone, and I am tracking changes in it, so anyone may feel free to change their project liaison or add or remove team members and I will be notified of the change.) > Colleen Thanks Colleen for the update and the note reminder ! I will update the cyborg team progress on wiki paget later. Regards, Yumeng

1 0

[meta][K8s][API][Extended Maintenance][Operation Docs] Change SIG to Advisory status
by Rico Lin 28 Nov '19

28 Nov '19

Dear SIG members and chairs To follow the discussion in Meta SIG PTG room [1]. I would like to propose to change the following SIGs to Advisory status [2] to represent the SIG stays around for provide help, make sure everything stays working and provide advice when needed. - K8s SIG - API SIG - Extended Maintenance SIG - Operation Docs SIG If you think your SIG should not belong to `advisory` statue. Please advise from the following statuses: - active: SIG reaches out for discussion and event, have plans for the current cycle, host meetings or send ML out regularly. - forming: SIG still setting up. - advisory: SIG stays around for help, make sure everything stays working and provide advice when needed. - complete: SIG completes its mission. If that sounds correct, I need at least one chair from each SIG +1 on [2], so we can make sure it's what SIGs agreed on. [1] https://etherpad.openstack.org/p/PVG-meta-sig [2] https://review.opendev.org/#/c/695625/ -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

3 4

[meta-sig] Add Thierry Carrez to core reviewer
by Rico Lin 28 Nov '19

28 Nov '19

I would like to propose adding Thierry to core reviewer for governance-sigs I don't think anyone will doubt his knowledge of maintaining governance-sigs repo. He will be able to do core review on all patches. To create SIG patch, it will require both UC and TC to give their blessing. That means besides Amy's +2, we only need Thierry or mine +2 to approve the workflow. Let me know what you think if you have other thoughts, otherwise, I will add him in core think week. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

2 2