| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-12 | |||
| 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 | |
| 13:30:53 | stephenfin | jaypipes, mriedem: For later, do you think this is ready to go https://review.openstack.org/#/c/480616/ ? | |
| 13:30:53 | jaypipes | By default, it appears in the response for administrative users only. | |
| 13:30:57 | mriedem | super fun that we kept the prefix... | |
| 13:31:00 | jaypipes | that might be the issue.. | |
| 13:31:16 | mriedem | stephenfin: with all of those failing tests? | |
| 13:31:31 | stephenfin | Unrelated failures | |
| 13:31:39 | jaypipes | stephenfin: I can look at it in a bit. | |
| 13:31:46 | mriedem | jaypipes: we could certainly make a specific policy rule for that | |
| 13:32:14 | stephenfin | ta | |
| 13:32:20 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Undeprecate the 'dhcp_domain' option https://review.openstack.org/480616 | |
| 13:32:25 | mriedem | stephenfin: i would have to load that context back into my head, because i remember the session in sydney about this and we were going to try and use the dns_network info from neutron if it was available, and change the behavior on the option to avoid backward compat issues | |
| 13:33:04 | mriedem | https://etherpad.openstack.org/p/YVR18-novaneutron-ops-cross-project-session | |
| 13:33:13 | stephenfin | mriedem: Ideally yes, but it seems that's probably an RFE more than a bugfix https://review.openstack.org/#/c/480616/6/nova/api/metadata/base.py@549 | |
| 13:33:16 | sean-k-mooney | yes i rememebr that being the direction | |
| 13:34:02 | sean-k-mooney | we coudl do both. stephenfin fix corrects the edgecase wehre the config value is set to None | |
| 13:34:28 | mriedem | stephenfin: that change isn't what was proposed in that forum session | |
| 13:34:31 | sean-k-mooney | the reading it form neutron is realitvly simple change on top | |
| 13:34:51 | mriedem | because gary is right - if the neutron network doesn't have dns then it's broken | |
| 13:35:09 | stephenfin | mriedem: It is not. It's a stopgap because I think the change in the forum session probably needs a spec | |
| 13:35:35 | stephenfin | so I need to undeprecate it so people can keep doing what they're doing until I've time to write that spec | |
| 13:35:44 | stephenfin | that's my thinking anyway | |
| 13:37:24 | sean-k-mooney | so im not sure if this is a spec or speclesss blueprint but keeping it simply i woudl personally just use teh neutron value if set and fall back to the nova config value if not | |
| 13:38:02 | stephenfin | sean-k-mooney: Other way round, surely, to avoid breaking the upgrade path | |
| 13:38:25 | sean-k-mooney | that is what i woudl expect as an enduser but with that said the OS-EXT-SRV-ATTR:hostname field should not contain the FQDN | |
| 13:38:48 | stephenfin | Aye. Possible (microversion) change there | |
| 13:39:11 | sean-k-mooney | stephenfin: no i mean if we want to expose an FQDN call it FQDN | |
| 13:39:26 | sean-k-mooney | we shoudl not expose an FQDN in a hostname field | |
| 13:39:47 | sean-k-mooney | so microver for a new file din server-details | |
| 13:40:01 | sean-k-mooney | possibelwithout the OS-EXT-SRV-ATTR: prefix and proably not admin onle | |
| 13:40:12 | sean-k-mooney | that definetly would need a spec actully | |
| 13:42:05 | mriedem | stephenfin: comments in your patch | |
| 13:43:02 | stephenfin | ta | |
| 13:44:07 | sean-k-mooney | oh the hostname is already an FQDN in some cases... of couse it is. | |
| 14:01:47 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add get_compute_nodes_by_host_or_node() https://review.openstack.org/650877 | |
| 14:01:48 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Pass target host to RequestGroup.in_tree https://review.openstack.org/650878 | |
| 14:01:48 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Query `in_tree` to placement https://review.openstack.org/649535 | |
| 14:05:14 | cdent | dansmith: os-traits release: https://review.openstack.org/652079 | |
| 14:05:30 | dansmith | sweet, thanks | |
| 14:05:37 | cdent | I'll start exploring the tox-siblings stuff next week | |
| 14:06:23 | dansmith | cdent: what in there makes it independent vs. whatever it is now? | |
| 14:06:41 | cdent | simply that it is in the _independent dir | |
| 14:07:28 | cdent | dansmith: I had the same question. I figured there must be a yaml file somewhere that declares what cycle something follows, but apparently it is per release | |
| 14:07:39 | dansmith | ah | |
| 14:07:52 | dansmith | but... it was before? | |
| 14:08:01 | dansmith | or 0.1.0 was before | |
| 14:09:57 | cdent | there's was a 0.1.0 which was the very first release | |
| 14:10:13 | cdent | then it moved to being in cycles, so there are yaml files in deliverables/$CYCLE | |
| 14:10:24 | cdent | and now it moves back to _independent | |
| 14:10:41 | dansmith | gotcha okay | |
| 14:10:58 | dansmith | I guess it's the unix "everything is a file" philosophy :) | |
| 14:11:43 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Undeprecate and rename the 'dhcp_domain' option https://review.openstack.org/480616 | |
| 14:16:02 | stephenfin | mriedem: I had to move that option in order to add it to the metadata file, so I also took the opportunity to rename it (since nova-net should be going away this cycle). Not entirely happy with the name so open to suggestions | |
| 14:21:22 | mriedem | stephenfin: why not just leave the option name as dhcp_domain? | |
| 14:23:53 | mriedem | couple more comments | |
| 14:24:02 | mriedem | i'm not sure what you mean by "its been repurposed" | |