| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-03 | |||
| 16:46:40 | kashyap | dasp: If someone modified the same area of code that you're working on and that got merged; you'll need to do a bit of conflict/rebasing -- which can be worked out with more experienced contributors :-) | |
| 16:46:48 | kashyap | Err, I meant dcapone2004 --^ | |
| 16:47:27 | dcapone2004 | I will definitely take a look and play around...would love to contribute and by doing so, I know I would indirectly learn a whole bunch more about openstack in general | |
| 16:58:39 | stephenfin | sean-k-mooney: gibi: bauzas: (fore after the meeting) before I send this email, are we sure we want to strip everything after the first period as opposed to replacing periods with dashes? | |
| 16:58:47 | stephenfin | *for | |
| 16:59:21 | sean-k-mooney | either of those i coudl be ok with | |
| 16:59:58 | sean-k-mooney | periods to dashes is the recommend transformation in the RFS and docs for /etc/hostname and systemd-hostnamed | |
| 17:00:25 | sean-k-mooney | just using the first segment is acutlly striping the domain and using the hostname for the host name field | |
| 17:00:56 | sean-k-mooney | striping woudl be using the dns "host name" for the non DNS "hostname" | |
| 17:01:39 | sean-k-mooney | those should generally be the same but are not required to be. | |
| 17:01:48 | bauzas | stephenfin: I'm personnally on the former side | |
| 17:02:05 | artom | bauzas, https://bugzilla.redhat.com/show_bug.cgi?id=1721068#c41 oh yeah we did | |
| 17:02:05 | openstack | bugzilla.redhat.com bug 1721068 in openstack-nova "allocations database is not properly cleaned" [Medium,Closed: errata] - Assigned to sbauza | |
| 17:02:16 | artom | (QE it on Queens, I mean) | |
| 17:02:21 | bauzas | changing periods to dashes is less easy to explain in terms of backportability IMHO | |
| 17:02:23 | sean-k-mooney | gibi: QE is quality engenering basically our test engineeres | |
| 17:02:28 | gibi | thanks | |
| 17:02:36 | sean-k-mooney | gibi: so QE'd just means tested by them | |
| 17:02:42 | bauzas | artom: I know I'm old but I remembered this | |
| 17:03:02 | stephenfin | bauzas: same thing, no? The hostname is going to be different in both cases | |
| 17:03:18 | sean-k-mooney | bauzas: reading the orginal unicode bug i woudl consider the current unicode bhavior to be invalid and actully a bug | |
| 17:03:21 | gibi | as we consider the audit a big win, and we did backported nova-manage commands in the past. I'm OK to take the risk | |
| 17:03:27 | gibi | and merge the backports | |
| 17:03:29 | artom | bauzas, hehe | |
| 17:03:33 | artom | So the train one wasn't so bad: https://review.opendev.org/c/openstack/nova/+/720838 | |
| 17:03:35 | gibi | but I don't have +2 on stable :) | |
| 17:03:48 | bauzas | stephenfin: I mean that I feel reasonably confident to explain to angry users that we consider that a FQDN isn't a hostname | |
| 17:03:59 | bauzas | and that we only spoke of a server name | |
| 17:04:41 | stephenfin | I'm worried about users with instance names like 'test-server.1', 'test-server.2', ... | |
| 17:04:46 | stephenfin | or 'ubuntu18.04' | |
| 17:05:12 | bauzas | the first case seems weirdo to me | |
| 17:05:16 | gibi | hm, test-server.1 and test-server.2 becomes test-server as a hostname in the geuest | |
| 17:05:20 | sean-k-mooney | so as an exampel we are proposign if servername=example.fqdn then instance.hostname==example and instance.display_name==example.fqdn | |
| 17:05:22 | bauzas | the second case is indeed somehow hard to convince | |
| 17:05:39 | bauzas | gibi: and I'm cool with this | |
| 17:05:52 | bauzas | (to have duplicate hostnames) | |
| 17:05:53 | stephenfin | sean-k-mooney: yes, and the alternative is instance.hostname=example-fqdn | |
| 17:06:05 | sean-k-mooney | yes | |
| 17:06:31 | sean-k-mooney | so if we maintain dispaly name that means that nova show example.fqdn will work in both cases | |
| 17:06:36 | sean-k-mooney | so ti wont affect server show | |
| 17:06:41 | sean-k-mooney | or list | |
| 17:06:54 | gibi | yeah, I agree not to affect server show and list | |
| 17:06:55 | stephenfin | Yes, it'll only affect people relying on cloud-init, which you're saying is already broken for FQDN? | |
| 17:07:00 | bauzas | just being clear, don't touch display_name ! | |
| 17:07:08 | stephenfin | *cloud-init for DNS integration | |
| 17:07:09 | sean-k-mooney | so it will only effect what is in the metadata and passed to designate | |
| 17:07:27 | bauzas | hangouts, folks ? | |
| 17:07:48 | stephenfin | isn't a bit late for you Europeans? | |
| 17:07:49 | bauzas | actually, my wife will kill me | |
| 17:07:52 | stephenfin | yeah :) | |
| 17:07:56 | gibi | mine too | |
| 17:07:58 | sean-k-mooney | yes with designate you get test-dns.invalid.dns.cloud.seanmooney.info for a servername=test-dns.invalid.dns via dns | |
| 17:08:01 | bauzas | stephenfin: dude, you're part of Europe | |
| 17:08:11 | stephenfin | *continental Europeans | |
| 17:08:12 | stephenfin | ;) | |
| 17:08:17 | bauzas | on a small isolated island tho | |
| 17:08:18 | gibi | :D | |
| 17:08:30 | sean-k-mooney | bauzas: its the brit in him showing :P | |
| 17:08:47 | bauzas | well, I actually feel isolated too | |
| 17:08:49 | gibi | push this two option ack to the ML: a) truncate b) replace with - | |
| 17:08:50 | bauzas | anyway | |
| 17:08:53 | bauzas | gibi: +1 | |
| 17:08:59 | stephenfin | gibi: good call; me does that | |
| 17:09:06 | gibi | sleep on it | |
| 17:09:11 | sean-k-mooney | cool that work for me too | |
| 17:09:14 | gibi | then try to close this out next week | |
| 17:09:21 | gibi | when stephenfin is back | |
| 17:09:22 | bauzas | stephenfin: clarify there are only two options and that we're about to backport the chosen | |
| 17:09:37 | gibi | ^^ +1 | |
| 17:10:02 | sean-k-mooney | do we need a workaround flag for this | |
| 17:10:05 | sean-k-mooney | for the backports | |
| 17:10:05 | artom | Random idea | |
| 17:10:13 | bauzas | (but again, from an ops pov (well from the last decade), I just feel that naming your server with 'x.y' is either very smart or totally crazy | |
| 17:10:18 | artom | You can set the port's dns_name "manually" via the Neutron API | |
| 17:10:23 | bauzas | sean-k-mooney: NO | |
| 17:10:34 | artom | So... why not just stop doing it automagically when Nova creates/updates the port? | |
| 17:10:37 | sean-k-mooney | bauzas: ok | |
| 17:10:50 | artom | And let people pick their own hostname that way | |
| 17:10:53 | sean-k-mooney | artom: only with designate | |
| 17:10:59 | bauzas | yeah | |
| 17:11:07 | sean-k-mooney | well or a vey new extenion i think | |
| 17:11:07 | artom | sean-k-mooney, not based on https://docs.openstack.org/api-ref/network/v2/index.html?expanded=update-port-detail,show-port-details-detail#update-port | |
| 17:11:09 | sean-k-mooney | ill check | |
| 17:11:21 | bauzas | and that's exactly why I think that nova shouldn't deal with TLDs in their server hostnames | |
| 17:11:35 | artom | Like, the original BZ we have is because Neutron exploded | |
| 17:11:38 | artom | Not Designate | |
| 17:11:53 | bauzas | but I can recognize that the dash conversion seems kinda more acceptable to users | |
| 17:12:48 | bauzas | anyway, /me needs to bail out | |
| 17:12:51 | bauzas | ++ | |
| 17:13:07 | gibi | o/ | |
| 17:13:19 | stephenfin | o/ | |
| 17:13:46 | sean-k-mooney | artom: im pretty sure nova used to explode at one point too with some of the shared nova net code | |
| 17:14:02 | sean-k-mooney | artom: the orginal bz was in my dev cloud in intel | |
| 17:14:18 | artom | sean-k-mooney, bz or launchpad bug? | |
| 17:14:20 | sean-k-mooney | it was filed by someone on my team after i told them it was never supported | |
| 17:14:27 | sean-k-mooney | sorry the launch pad bug | |
| 17:14:44 | artom | Well, nova-network doesn't exist anymore, so... :) | |
| 17:16:09 | sean-k-mooney | i think it used to explode somewhere in https://github.com/openstack/nova/blob/stable/train/nova/network/minidns.py | |
| 17:17:27 | sean-k-mooney | this si where we are current failing right https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L678-L686 | |
| 17:20:03 | artom | sean-k-mooney, no, based on https://bugzilla.redhat.com/show_bug.cgi?id=1872314 we actually make the request to Neutron | |