Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-03-21
16:53:20 bauzas this is about removing Xena computes support for Zed
16:53:34 bauzas but we definitely need to discuss this at the PTG
17:30:55 gibi_pto bauzas: correct, we have to change that limitation in the future to support N-2 -> N upgrades
17:31:29 bauzas I'll leave this change open until tomorrow and we'll discuss at the nova meeting
17:31:34 sean-k-mooney gibi_pto: well that is the topic to discuss at the PTG apprently we dont actully have too but likely should
17:32:12 sean-k-mooney gibi_pto: just repeating what i have heard but appretly live rolling upgrade supprot for n-2 is left to the projects to opt in too
17:33:08 sean-k-mooney so if we elect to supprot n-2 rolling upgrades upstream then we shoudl alter that check and add a job to validate it if we dont then we could keep it at n-1
17:33:27 gibi_pto ahh, OK, lets talk that through on the PTHG
17:33:29 gibi_pto PTG
17:33:57 gibi_pto bauzas: that change fails in grenade on the service version check
17:34:11 gibi_pto https://zuul.opendev.org/t/openstack/build/a24b974ae9fd487694724da795bfcd2a/log/controller/logs/screen-n-cond.txt#1140
17:34:12 dansmith bauzas: I think we should have something like this for nova: https://docs.openstack.org/cinder/latest/contributor/gerrit.html#ci-job-rechecks
17:34:36 dansmith some discussion of late in the tc about how most people just do blind rechecks all the time
17:35:09 dansmith probably don't need that much detail for nova given that we don't have all the drivers, but still, I see a lot of "recheck" with no explanation, which I think often means no inspection
17:35:40 dansmith I'm hoping we'll have some general direction out of the tc about this, but would be nice to jumpstart in the nova community with reminders and constructive peer pressure :)
17:36:50 gibi_pto dansmith: I suppor that idea!
17:37:11 dansmith gibi_pto: I support your support :)
17:37:21 sean-k-mooney we used to have a section that said you should file a bug and add an elastic recheck query i think
17:37:23 dansmith however, I do not support you spending pto hanging out in irc :P
17:37:24 gmann like neutron, we can monitor how many recheck for this week we had
17:38:05 dansmith sean-k-mooney: yeah, but we need more constructive peer pressure regardless.. clear documentation to point to would be helpful when doing that
17:38:16 gmann s/gibi_pto/gibi_pto_but_work_on_irc :)
17:38:24 dansmith sean-k-mooney: if we've got it, then cool, but a concerted team-wide effort is needed I think
17:38:40 gibi_pto nah, I just randomly hanging around :)
17:38:40 dansmith gmann: paid time on work is just work :P
17:38:41 sean-k-mooney dansmith: i think we removed it at som epoint im checking to see if we still do
17:38:53 sean-k-mooney i tought it was in https://github.com/openstack/nova/blob/master/doc/source/contributor/code-review.rst but not seeign it
17:40:21 dansmith I can certainly write up some stuff
17:40:23 sean-k-mooney its also not in our testing doc https://github.com/openstack/nova/blob/master/doc/source/contributor/testing.rst so ya i think we remved it
17:47:49 sean-k-mooney dansmith: this is proably where it need to be updated https://opendev.org/openstack/nova/src/branch/master/doc/source/contributor/process.rst#how-can-i-get-my-code-merged-faster
17:48:23 sean-k-mooney we currently say """If you're fixing something that only occasionally failed before, maybe recheck a few times to prove the tests stay passing."""
17:48:41 sean-k-mooney but we dont give guidnce on when its appropate to recheck in general
17:48:51 gmann dansmith: or may be to writeup in project-team-guide and point projects doc to that ?
17:49:45 sean-k-mooney gmann: we do link to this https://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing
17:50:12 sean-k-mooney we used to have a version fo that in nova
17:50:48 gmann I mean to tell "no blind recheck" and 'best way to check logs and find issue' explicitly
17:50:51 sean-k-mooney step 2 """Examine the console log or other relevant log files to determine the cause of the error. If it is related to your change, you should fix the problem and upload a new patchset. Do not use “recheck”."""
17:52:45 sean-k-mooney we do link to that form our testing.rst doc
17:53:13 gmann yeah, I think due length of this doc it got hidden and people ignore to read the complete doc. we can add link to this doc for details but have a explicit section about recheck and how to use it in best way
17:53:21 gmann dur to
17:53:52 sean-k-mooney if we had a centralised one we coudl have zuul link top it when it fails
17:54:00 sean-k-mooney by updating the failure message
17:55:04 sean-k-mooney in any case it took me 5 mins to find that and i more or less know what im looking for so a new contibutor is likely not going to find it
17:56:02 gmann true
18:44:13 stephenfin sean-k-mooney: https://review.opendev.org/c/openstack/os-traits/+/833826 easy patch
18:47:01 sean-k-mooney stephenfin: ah has the discussion on that been resovled
18:47:25 sean-k-mooney i saw the thread you started but did not keep track of it while i was off
18:49:14 sean-k-mooney oh its just the reference syntax in zuul. that keeps duplicaiton down at least.
18:49:29 sean-k-mooney the zuul change that is https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286/2/zuul.d/project-templates.yaml
18:54:34 sean-k-mooney stephenfin: ok done.#
18:54:43 stephenfin spot on, thanks!
18:57:42 sean-k-mooney did you also do os-resource classes
18:59:01 sean-k-mooney stephenfin: dont see it here https://review.opendev.org/q/topic:add-python3-unversioned-jobs but i think its independent too https://github.com/openstack/releases/blob/master/deliverables/_independent/os-resource-classes.yaml
18:59:21 stephenfin Oh, my hacky script probably just missed that
19:00:16 sean-k-mooney i need to add a PTG topic about this by the way
19:00:32 sean-k-mooney we might want to merge those back into placment
19:00:53 sean-k-mooney we have a cirular dep issue with testing and releases
19:01:29 sean-k-mooney we can either relax the test that assert the amount of traits/resouce classes or we can put them all in the same repo
19:02:06 sean-k-mooney stephenfin: im going to go eat something. if you push a patch add me and ill look at it tomorrow
19:02:54 opendevreview Stephen Finucane proposed openstack/os-resource-classes master: Update CI to use unversioned jobs template https://review.opendev.org/c/openstack/os-resource-classes/+/834537
19:03:01 stephenfin sean-k-mooney: Cool. It's there btw ^
19:04:08 opendevreview Merged openstack/os-traits master: Update CI to use unversioned jobs template https://review.opendev.org/c/openstack/os-traits/+/833826
19:13:18 gmann stephenfin I missed it for os-traits but please update setup.cfg too to reflect the tested versions https://review.opendev.org/c/openstack/os-resource-classes/+/834537
19:14:30 stephenfin gmann: I'd rather not mix those two things though I'll admit they're related. Do we want to bump 'python-requires' also?
19:14:38 gmann also, like i mentioned in ML reply, I have added to remove the release specific templates itself which will fix all these issue and less work during releases https://etherpad.opendev.org/p/tc-zed-ptg#L108
19:15:37 gmann stephenfin: yes we can bump python-requires also. They are related as if we do not test py3.6/7 then we should update it in classifier too.
19:16:01 gmann in zed release template we will do the same for branched repo also
19:16:24 stephenfin Oh, that's a good idea
19:16:55 gmann in Zed: python-requires >= py3.8 and remove py3.6 and py3.7 from list
19:17:26 stephenfin _Personally_, I'd question the value the classifiers bring. They aren't used by any tooling that I'm aware of, unlike python-requires. I wonder if we should get rid of them?
19:19:14 gmann I think someone might be checking it from pypi doc but yes I do not have anyone asked about it explicitly
19:25:45 dansmith gmann: yeah, maybe some centralized docs would be good
19:25:57 dansmith gmann: I definitely think we need PTLs to get the word out though
19:26:56 gmann dansmith: +1 on PTL one. I like to neutron way to track it in their weekly meeting. that is something we can suggest PTL to do.
19:27:24 gmann I have added it in TC+PTL PTG etherpad
19:30:58 dansmith yeah
#openstack-nova - 2022-03-22
10:17:57 opendevreview Stephen Finucane proposed openstack/os-resource-classes master: setup: Replace dashes with underscores, add links https://review.opendev.org/c/openstack/os-resource-classes/+/834644
10:17:57 opendevreview Stephen Finucane proposed openstack/os-resource-classes master: setup: Update Python testing classifiers https://review.opendev.org/c/openstack/os-resource-classes/+/834643
10:51:30 zigo Is there a way to evacuate a host that has 3 VMs that have affinity? Can I somehow tell nova "migrate them together" ?
12:41:50 opendevreview anguoming proposed openstack/nova master: fix the bug of the log line has no request_id info at source host when live migration https://review.opendev.org/c/openstack/nova/+/834677
12:47:34 opendevreview anguoming proposed openstack/nova master: fix the bug of the log line has no request_id info at source host when live migration https://review.opendev.org/c/openstack/nova/+/834677
12:50:53 stephenfin sean-k-mooney: This isn't hugely important, but could you look at https://review.opendev.org/c/openstack/nova/+/723572/ and https://review.opendev.org/c/openstack/nova/+/723573/ today?
12:54:49 opendevreview anguoming proposed openstack/nova master: fix the bug of the log line has no request_id info at source host when live migration https://review.opendev.org/c/openstack/nova/+/834677
12:58:54 opendevreview Stephen Finucane proposed openstack/nova master: objects: Don't use generic 'Field' container https://review.opendev.org/c/openstack/nova/+/738239
12:58:55 opendevreview Stephen Finucane proposed openstack/nova master: objects: Use imports instead of type aliases https://review.opendev.org/c/openstack/nova/+/738018
12:58:55 opendevreview Stephen Finucane proposed openstack/nova master: objects: Remove unnecessary type aliases, exceptions https://review.opendev.org/c/openstack/nova/+/738240
12:58:56 opendevreview Stephen Finucane proposed openstack/nova master: WIP: add ovo-mypy-plugin to type hinting o.vos https://review.opendev.org/c/openstack/nova/+/758851
12:58:56 opendevreview Stephen Finucane proposed openstack/nova master: objects: Remove wrappers around ovo mixins https://review.opendev.org/c/openstack/nova/+/738019
13:00:01 sean-k-mooney stephenfin: sure ill take a look at them now while i have context on this they look reasonably short and i see gmann has already reviewed them
13:00:29 sean-k-mooney getting rid fo the dict compat layer has been long overdue
13:00:47 sean-k-mooney i woudl be nice not to have to review for new usease of them as a dict
13:02:21 opendevreview Stephen Finucane proposed openstack/nova master: doc: Remove useless contributor/api-2 doc https://review.opendev.org/c/openstack/nova/+/828599
13:54:03 EugenMayer (Request-ID: req-7c68445d-a8b5-4ef6-a11d-6f037402d92a) - so basically one of my instances references a flavor that no longer exists. Is there a way to somehow fix this?
13:54:03 EugenMayer When deploying via terraform it and changing an flavor (thus replacing it) it seems like the old flavour was removed but not yet 'removed from the instance it has been used' and then it all failed. Now i'am stuck with Unable to retrieve instance size information. Details Flavor 384bc436-a0cb-4e4a-80d1-26dd03743061 could not be found. (HTTP 404)
14:48:12 artom Anyone able to run functional tests on ussuri?
14:48:28 artom Trying to figure out if it's something local to me, or more widespread
14:48:48 artom Seems to be hanging/timing out on:
14:48:49 artom functional installdeps: -chttps://releases.openstack.org/constraints/upper/ussuri, -r/home/artom/src/nova/requirements.txt, -r/home/artom/src/nova/test-requirements.txt, openstack-placement>=1.0.0
14:50:14 sean-k-mooney i can try it one sec
14:50:17 artom Seems to be doing... something?

Earlier   Later