| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-03 | |||
| 15:30:05 | noonedeadpunk | found it here https://zuul.opendev.org/t/openstack/build/0af9364cc9094b5096899ed7693a9f60/log/logs/host/nova-conductor.service.journal-10-50-46.log.txt#2431 | |
| 15:31:55 | sean-k-mooney | we are not using sevedor to load this in oslo cache or in nova | |
| 15:32:33 | noonedeadpunk | um..... | |
| 15:32:56 | sean-k-mooney | im wondering if this is coming form oslo.config | |
| 15:33:22 | noonedeadpunk | can hardly imagine path of the imports tbh | |
| 15:33:54 | noonedeadpunk | But I think it appeared only in V since in U haven't seen that message | |
| 15:33:57 | sean-k-mooney | we are using oslo cache | |
| 15:34:20 | sean-k-mooney | but i dont see it directly using sevedor in its code | |
| 15:34:48 | noonedeadpunk | ah, yes, might be oslo.config that using it, right | |
| 15:34:54 | sean-k-mooney | https://codesearch.opendev.org/?q=stevedore&i=nope&files=&excludeFiles=&repos=openstack/nova,openstack/oslo.cache,openstack/oslo.config,openstack/oslo.privsep | |
| 15:34:58 | sean-k-mooney | that is what im looking at | |
| 15:35:44 | sean-k-mooney | we use stevador for 3 things in nova, extra spec validator, schudler dirvers and metric monitors | |
| 15:36:10 | sean-k-mooney | oslo cache and oslo privsep dont use it at all it just in ther lower constraits | |
| 15:36:20 | sean-k-mooney | because they depend on oslo.config which does use it | |
| 15:37:41 | sean-k-mooney | it might be https://github.com/openstack/oslo.cache/commit/308f49aaaad554573aeff8ddc68c39ff7fe57438 | |
| 15:37:50 | noonedeadpunk | seem like https://opendev.org/openstack/oslo.config/src/branch/master/oslo_config/cfg.py#L2152-L2154 | |
| 15:37:53 | noonedeadpunk | yeah | |
| 15:38:31 | sean-k-mooney | ya | |
| 15:40:26 | sean-k-mooney | anyway this seams to be an oslo issue in one form or another | |
| 15:41:02 | noonedeadpunk | yeah, agreed - thanks for helping out - will go and chase oslo folks | |
| 15:57:13 | gibi | nova weekly meeting starts in 3 minutes on #openstack-meeting-3 | |
| 15:57:29 | gmann | gibi: sean-k-mooney we need to put API patch changes at the end which bump the microversion and all code cleanup as first in the series. and rebase is so hard for microversion race i think we end up doing this in every cycle. brin is not online I will check with him on policy stuff help | |
| 15:57:57 | gmann | ypo. * rebase is *not* so hard for microversion | |
| 15:59:55 | gibi | gmann: most of the changes needed for the tenant_id bp is actually changes in the API code so we cannot frontload tha backend change as there is none | |
| 16:00:50 | gmann | gibi: yeah but i think code cleanup also there which i suspect a large chunk but need to grep and see. | |
| 16:01:31 | gmann | I think having all changes up and zuul +1 then we can start merging. | |
| 16:01:36 | gibi | gmann: I thin the majority of the change line vise is api sample changes and test code, and both need to have the microversion bump already in place | |
| 16:02:02 | gibi | gmann: yes, that would be ideal, but Brin noted that this will be a lot of patches | |
| 16:02:22 | gmann | humm | |
| 16:02:23 | gibi | so we talked about options | |
| 16:02:38 | gibi | but at the end we found no viable option other than having all the patches | |
| 16:02:55 | gibi | (if we want to keep them in a single microversion) | |
| 16:03:29 | gmann | and base patch with -W until all are ready ? | |
| 16:13:07 | gibi | yeah, basically | |
| 16:13:54 | gibi | if we could merge every other API impacting changes accepted to W then maybe we can consider merging some of the tenant_id stuff or at least reconsider it | |
| 16:14:14 | gibi | so now it is all or nothing | |
| 16:17:47 | gmann | gibi: +1 | |
| 16:21:06 | gibi | sean-k-mooney: if you are around we need you in #openstack-meeting-3 | |
| 16:37:38 | dcapone2004 | sean-k-mooney: sorry, I had a meeting I needed to attend...I was always thinking about it as a feature request .... and I wish I had the capacity to contribute way more than I do....I know python, but I have never done formal software development, so the whole submitting patches, code review process escapes me :-( | |
| 16:42:21 | kashyap | dcapone2004: FWIW, it's actually gotten significantly simpler; OpenStack Gerrit also provides a "sandbox" to practise your workflow | |
| 16:42:46 | kashyap | (https://docs.opendev.org/opendev/infra-manual/latest/sandbox.html) | |
| 16:43:05 | dcapone2004 | nteresting...I will take a look at that | |
| 16:43:15 | sean-k-mooney | dcapone2004: thats ok. can you file a blueprint for this https://blueprints.launchpad.net/nova/+addspec | |
| 16:43:55 | sean-k-mooney | dcapone2004: basically like a bug but descibing your use case, what we have learns and what we your are trying to do | |
| 16:44:03 | dcapone2004 | sean-k-mooney: that I can do | |
| 16:44:33 | sean-k-mooney | if you can include the 4 enlightments that were need in your case that will helpt o document them | |
| 16:44:38 | dcapone2004 | kashyap: The part that more eludes more than the simple checkout check in or review process is the whole multiple people working on the same thing at once and how that all gets merged | |
| 16:46:00 | kashyap | dcapone2004: It takes some time getting used to, but it's not as complex - if you're focusing on one small part of the code | |
| 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 | openstack | bugzilla.redhat.com bug 1721068 in openstack-nova "allocations database is not properly cleaned" [Medium,Closed: errata] - Assigned to sbauza | |
| 17:02:05 | artom | bauzas, https://bugzilla.redhat.com/show_bug.cgi?id=1721068#c41 oh yeah we did | |
| 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 | |