| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-12 | |||
| 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 | jaypipes | By default, it appears in the response for administrative users only. | |
| 13:30:53 | stephenfin | jaypipes, mriedem: For later, do you think this is ready to go https://review.openstack.org/#/c/480616/ ? | |
| 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: Query `in_tree` to placement https://review.openstack.org/649535 | |
| 14:01:48 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Pass target host to RequestGroup.in_tree https://review.openstack.org/650878 | |
| 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" | |
| 14:26:24 | kashyap | stephenfin: Bike-shedding: if the new name is "domain", beware that Nova frequently uses that term in context of "libvirt domains" | |
| 14:26:24 | stephenfin | mriedem: It seemed odd, given that it's not really anything specific to DHCP as used here | |
| 14:26:25 | melwitt | dansmith: could you take a look at the question I asked on the discover_hosts collision patch warn? I'm getting confused about whether I should return 0 if strict=False https://review.openstack.org/651947 and then also tssurya pointed out that map_instances skips DBDuplicateEntry | |
| 14:26:49 | stephenfin | kashyap: Yeah, it also easy interpret as the domain of the metadata service or something. Not a fan | |
| 14:27:10 | stephenfin | Eh, I haven't got a better idea so back to dhcp_domain it is | |
| 14:28:15 | kashyap | stephenfin: fqdn_name? | |
| 14:28:24 | mriedem | just leave it dhcp_domain | |
| 14:28:33 | kashyap | Yeah | |
| 14:28:50 | kashyap | (Also: the 'n' in 'fqdn' is name) | |
| 14:29:36 | artom | RAS syndrome! | |
| 14:32:12 | dansmith | melwitt: done | |
| 14:32:18 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Undeprecate and move the 'dhcp_domain' option https://review.openstack.org/480616 | |
| 14:32:27 | melwitt | dansmith: ty | |
| 14:33:03 | stephenfin | mriedem: back to dhcp_domain it is ^ | |
| 14:37:48 | melwitt | I was thinking about it in the inverse, keep running under zero is returned, not keep running until nonzero is returned. no wonder I was confused xD | |
| 14:43:30 | melwitt | *until | |
| 14:43:47 | mriedem | i also commented because everyone loves a good bike shed, not sure how my comments align with others | |
| 14:44:02 | dansmith | melwitt: well, I'm just going based on the existing behavior, not necessarily the right behavior | |
| 14:44:14 | melwitt | I see, yeah | |
| 14:45:48 | dansmith | mriedem: my preference is to just highlight the error and stop processing records, not skip and continue | |
| 14:45:59 | dansmith | which is why I think we should bail, | |
| 14:46:16 | dansmith | but I think the existing return code behavior means we return 1 until we find nothing else to do, then return 0 | |
| 14:46:27 | dansmith | and in that case, if we bail, we should return 1 so that something knows that there may be more stuff to do | |
| 14:47:37 | mriedem | the existing return code behavior depends on the --strict option | |
| 14:48:00 | dansmith | ...right | |
| 14:48:03 | mriedem | if you don't specify --strict it returns 0 unless something blows up | |
| 14:48:32 | dansmith | ...right, are you saying you want to preserve the non-strict nonzero behavior on error? | |
| 14:49:04 | dansmith | I thought she was specifically asking about what to do if --strict was passed | |
| 14:49:09 | melwitt | wait, I thought we return 0 until there's nothing more to do, and then return 1 when there's nothing to do? | |
| 14:49:14 | mriedem | if i'm running this on a cron or something and not specifying --strict, i don't want it to error out if it got a duplicate entry error because it either did the job or there wasn't anything to do, so i don't care | |
| 14:49:55 | dansmith | mriedem: but the job may very well be unfinished | |
| 14:50:13 | dansmith | melwitt: not currently, AFAICT | |
| 14:50:16 | mriedem | if we just blow up and stop processing sure | |