Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-12
07:17:17 alex_xu kashyap: thanks
07:20:25 kashyap alex_xu: On your question ... you're right: we're mentioning it as an "extra" flag because a certain named CPU model may not contain some important CPU flags, e.g IvyBridge does not contain 'pcid'.
07:21:13 kashyap (But the *host* itself is capable of it, and QEMU can recognize it. So we supply it explicitly)
07:22:05 kashyap I will answer on the review, so you can respond at your own pace :-)
07:27:51 alex_xu kashyap: for the use-case of config extra_flag, we want the IvyBridge + pcid, not just ensure pcid in the model of IvyBridge, right?
07:28:36 kashyap Exactly. We're specifying '+ pcid' because it is not included in the libvirt's "idea of IvyBridge", but host is capable of PCID
07:29:46 alex_xu kashyap: also, there won't have any model incompatible with pcid?
07:29:47 kashyap alex_xu: To refresh your memory:
07:30:16 kashyap (1) Intel Haswell, Broadwell, Skylake libvirt/QEMU models include 'pcid' by default.
07:30:48 kashyap (2) The libvirt / QEMU CPU models "Nehalem", "Westmere", "SandyBridge", and "IvyBridge" will _not_ expose the 'PCID' capability by default, even if the host CPUs by the same name include it. I.e. 'PCID' needs to be explicitly specified when using the said virtual CPU models.
07:31:25 alex_xu kashyap: nice refresh, that is interesting :)
07:31:43 kashyap alex_xu: Okay, was wondering if what I wrote above was useful :-)
07:32:07 alex_xu kashyap: so I guess the problem is that paragraph makes me confusing on what you want to check.
07:32:10 kashyap alex_xu: I wrote that documentation in Nova's documentation.
07:32:12 kashyap (And here too: https://kashyapc.fedorapeople.org/Reducing-OpenStack-Guest-Perf-Impact-from-Meltdown.txt)
07:32:34 kashyap alex_xu: Actually, I didn't write that original paragraph in the spec, Jack Ding wrote it
07:32:52 kashyap alex_xu: Let me think a bit more on to rephrase it to be more clear.
07:33:09 alex_xu kashyap: ah, sorry, I thought it was removed from the original spec
07:33:17 kashyap It was not
07:33:27 alex_xu kashyap: yea, thanks, good to be clear what is checked we want
07:36:22 kashyap alex_xu: As a general point: for most operators, using 'host-model' should suffice, because that will auto-add necessary CPU flags for Meltdown/Spectre
07:47:52 alex_xu kashyap: thanks, good to know
08:20:49 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Add get_compute_nodes_by_host_or_node() https://review.openstack.org/650877
08:20:49 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Pass target host to RequestGroup.in_tree https://review.openstack.org/650878
08:20:50 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Query `in_tree` to placement https://review.openstack.org/649535
08:23:07 openstackgerrit Boxiang Zhu proposed openstack/nova-specs master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645458
08:48:50 openstackgerrit Boxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule https://review.openstack.org/649963
09:22:05 openstackgerrit Boxiang Zhu proposed openstack/nova-specs master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645458
09:25:48 alex_xu boxiang: I think we can persistent the destination_host
09:26:05 alex_xu boxiang: since we reset it when do other migration, this is the rebuild https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L1034
09:27:31 kashyap gibi: lyarwood: I hope I answered your questions on the Secure Boot spec: https://review.openstack.org/#/c/506720/
09:27:35 kashyap Thanks for the review and questions!
09:27:50 boxiang alex_xu: let me take a look
09:29:25 openstackgerrit ya.wang proposed openstack/nova-specs master: Expose auto converge and post copy https://review.openstack.org/651681
09:33:18 boxiang alex_xu:Yeah, I see other migration will call reset_forced_destinations. I will make some changes later.
09:36:13 alex_xu boxiang: cool
09:36:31 alex_xu boxiang: I think I can +2 after you update
09:36:59 openstackgerrit Stephen Finucane proposed openstack/nova master: Bump to hacking 1.1.0 https://review.openstack.org/651553
09:37:00 openstackgerrit Stephen Finucane proposed openstack/nova master: hacking: Resolve E731 issues https://review.openstack.org/651554
09:37:00 openstackgerrit Stephen Finucane proposed openstack/nova master: hacking: Resolve W503 issues https://review.openstack.org/651555
10:28:09 openstackgerrit Stephen Finucane proposed openstack/python-novaclient stable/rocky: Add test for console-log and docs for bug 1746534 https://review.openstack.org/652033
10:28:10 openstack bug 1746534 in python-novaclient "encoding error when doing console-log" [High,Fix released] https://launchpad.net/bugs/1746534 - Assigned to Thomas Goirand (thomas-goirand)
10:28:28 openstackgerrit Stephen Finucane proposed openstack/python-novaclient stable/rocky: Add test for console-log and docs for bug 1746534 https://review.openstack.org/652033
10:29:14 openstackgerrit Stephen Finucane proposed openstack/python-novaclient stable/rocky: Add test for console-log and docs for bug 1746534 https://review.openstack.org/652033
10:29:16 openstack bug 1746534 in python-novaclient "encoding error when doing console-log" [High,Fix released] https://launchpad.net/bugs/1746534 - Assigned to Thomas Goirand (thomas-goirand)
10:33:39 openstackgerrit Merged openstack/nova-specs master: add spec for image metadata prefiltering https://review.openstack.org/647578
11:20:06 sean-k-mooney stephenfin: jaypipes do ye have time to review the sriov migration patches again. https://review.openstack.org/#/c/620115/34 https://review.openstack.org/#/c/629589/ jay the first one has not change since you reviewed it last and the second is now rebased thanks to adrianc
12:46:51 jaypipes sean-k-mooney: yes, will do this morning.
12:47:12 sean-k-mooney :)
12:48:22 sean-k-mooney i had addressed you comments in a previous revision and adrianc rebased it on his latest patch so that should be the only delta form what you saw before. if there is anythin else a miss let me know :)
13:01:23 openstackgerrit Merged openstack/nova stable/stein: Fix incomplete instance data returned after build failure https://review.openstack.org/647902
13:02:54 stephenfin Can someone remind me: do we still translate exceptions?
13:03:06 sean-k-mooney no not anymore
13:03:14 sean-k-mooney at least i dont think we do
13:05:01 sean-k-mooney stephenfin: looking at https://docs.openstack.org/oslo.i18n/latest/user/guidelines.html#choosing-a-marker-function
13:05:18 sean-k-mooney maybe we do i had tought we decided to stop translating them however
13:05:51 sean-k-mooney stephenfin: ah https://docs.openstack.org/oslo.i18n/latest/user/guidelines.html#log-translation
13:06:17 sean-k-mooney so ya as of pike we dont translate any logs
13:13:37 jaypipes stephenfin, sean-k-mooney: not sure how I failed to notice this before, but the compute API's GET /servers/{id}/detail endpoint does not return the DNS name of the instance. What is the canonical way of getting an instance's hostname?
13:14:17 sean-k-mooney jaypipes: the neutorn port will have it if you have designate deployed
13:14:57 sean-k-mooney if you are not using designate and are relying on the nova config option i guess it would be in the instance metadata somewhere
13:17:32 sean-k-mooney jaypipes: https://developer.openstack.org/api-ref/network/v2/index.html#id52
13:17:33 jaypipes sean-k-mooney: that's what I would have thought...
13:18:00 jaypipes this cluster is on Ocata with nova-network :(
13:18:42 sean-k-mooney oh then the cloud init metadata is your best bet. we have an api endpoint for that right?
13:19:15 jaypipes sean-k-mooney: a colleague is trying to get this information via the openstacksdk. :(
13:20:10 sean-k-mooney ah that could be tricky. stephenfin you did a deep dive on the metadata stuff recently for the doc any ideas?
13:20:30 sean-k-mooney jaypipes: stephenfin might be iun a 1:1 with our manger at the moment so there might be a delay
13:22:03 sean-k-mooney looks like its not in os-interface either
13:22:25 stephenfin sean-k-mooney, jaypipes: That's exposed via the metadata service, yes
13:23:03 sean-k-mooney stephenfin: any idea how you would query it outside of the vm
13:23:14 mriedem jaypipes: what's in the OS-EXT-SRV-ATTR:hostname param?
13:24:08 sean-k-mooney mriedem: i think that is just the name specifed when you created the vm without the rest of the fqdn. but honestly not sure with nova-net
13:24:08 stephenfin sean-k-mooney: Oh, outside it? That I don't know
13:24:49 stephenfin sean-k-mooney: fwiw, we (wrongly) use the nova-net domain stuff to generate a FQDN for the metadata service and other stuff
13:24:54 sean-k-mooney stephenfin: is /servers/{server_id}/metadata/{key} the same thing https://developer.openstack.org/api-ref/compute/?expanded=show-metadata-item-details-detail#list-all-metadata
13:25:10 mriedem no
13:25:13 stephenfin I tried fixing it at some point but gave up because there was a risk of breaking stuff
13:25:16 mriedem that's user-supplied metadata
13:25:22 sean-k-mooney stephenfin: if you deploying with nova-net then we correctly do that :)
13:25:25 mriedem this is the meta api hostname code https://github.com/openstack/nova/blob/03322bb517925a9f5a04ebdb41c3fd31e7962440/nova/api/metadata/base.py#L530
13:25:39 jaypipes mriedem: there isn't one.
13:25:55 stephenfin sean-k-mooney: https://review.openstack.org/#/c/480616/
13:26:28 sean-k-mooney mriedem: ah ok so we dont have a way to get the the cloud init metadata via the rest api then?
13:27:49 mriedem i'm not aware of something obvious no
13:27:55 sean-k-mooney stephenfin: oh i tought you ment it was wrong becasue we should be using the designate one. not it was borked even for nova-net
13:28:31 stephenfin sean-k-mooney: Nah, it's fine for nova-net so long as you don't unset 'dhcp_domain'. I was talking about the designate one
13:28:51 stephenfin Which I tried to do in an earlier revision but garyk pointed out that it would break stuff
13:29:22 jaypipes was OS-EXT-SRV-ATTR:hostname added in a microversion? I don't see it listed in the compute API reference.
13:29:39 mriedem no it's always been there, hence the prefix
13:29:48 sean-k-mooney jaypipes: i assume you/oath/nova-net dont have rdns ptr record to allow looking up the dns name from an ip?
13:29:54 mriedem https://developer.openstack.org/api-ref/compute/?expanded=show-server-details-detail#show-server-details
13:30:01 jaypipes mriedem: you mean OS-EXT-SRV-ATTR:hypervisor_hostname or OS-EXT-SRV-ATTR:host ?
13:30:09 mriedem neither
13:30:11 mriedem i mean OS-EXT-SRV-ATTR:hostname
13:30:15 stephenfin jaypipes: I see it in api-ref/source/servers.inc
13:30:25 stephenfin whatever that gets generated into
13:30:26 jaypipes ah, yeah. 2.3
13:30:38 jaypipes sorry mriedem
13:30:47 mriedem oh so it was exposed later

Earlier   Later