Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-09
08:30:23 gibi we need somebody other than stephen who feels good about +2ing https://review.opendev.org/#/c/700812 in lyarwood's series. that part of nova is not my strong suite so I'm only +1
08:31:21 bauzas gibi: sure thing, I'm available for upstream this week
08:32:41 brinzhang gibi: I have a question in https://review.opendev.org/#/c/712651/19/novaclient/v2/shell.py@2741
08:33:09 brinzhang gibi: do we need add default=None to --no-delete-on-termination? and why?
08:33:18 gibi brinzhang: let me check that
08:33:22 gibi bauzas: thanks
08:33:41 gibi brinzhang: I copied stephenfin's solution from the reworked 2.83 patch
08:34:21 brinzhang I reviewed the config_drive form stephenfin, I also find he also set for the --no-config-drive
08:34:28 gibi ohh
08:34:32 brinzhang I think it's ok, but I dont know why
08:34:39 gibi I will look
08:35:02 brinzhang s/ also set / also not set
08:35:29 gibi ahh, then I copied well at least :D
08:36:07 brinzhang gibi: yeah, I think stephenfin can answer why ^^
08:36:58 openstackgerrit Kevin Zhao proposed openstack/nova master: libvirt: change UEFI check to handle AArch64 better https://review.opendev.org/714311
08:37:23 bauzas gibi: stephenfin: mmm, something is still wrong with https://review.opendev.org/#/c/718461/3 https://5f439afd55f568b98179-509bae49365f8635e29d5b96780095d8.ssl.cf5.rackcdn.com/718461/3/check/openstack-tox-py37/bd3dc11/testr_results.html
08:38:17 gibi bauzas: yepp, I think the regex changed and therefore the name of the namespace changed, so the test needs to be updated
08:38:25 gibi I let stephenfin do that so we can +2 it
08:39:58 brinzhang bauzas: https://review.opendev.org/#/c/718357/ this patch and https://review.opendev.org/#/c/701430 from lyarwood all modified rest_api_version_history.rst, do you think is there a conflict?
08:43:48 gibi brinzhang: looking at the change they are separate by unchanged lines so I think git will manage to merge it
08:45:47 bauzas brinzhang: gibi: sorry a bit distracted due to the kids :)
08:46:28 brinzhang gibi: yes, it's ok, I tested in local used:
08:46:34 brinzhang git review -d 701430
08:46:39 brinzhang git review -x 718357
08:47:19 brinzhang I think I should simulate a scenario to check "git review -R", thanks gibi, bauzas
08:47:32 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in servers Policies https://review.opendev.org/662968
08:47:57 bauzas brinzhang: since recent revisions, Gerrit now tells you whether it would create a merge conflict
08:48:02 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in servers Policies https://review.opendev.org/662968
08:48:07 bauzas I mean, the Gerrit UI
08:48:59 gibi I never used git review. I like the full controll of git push <remote> <what>:refs/for/<branch>/topic
08:49:18 gibi I mean <topic>
08:49:24 brinzhang_ bauzas: yeah, I know, but that until the patch merged then we can know whether conflict from gerrit
08:49:45 huaqiang :qa
08:49:47 huaqiang exit
08:49:51 huaqiang :(
08:50:19 bauzas brinzhang: no, you can test on your local git repo
08:50:22 brinzhang_ ah, I was dropped, I think I missed what did you said above, gibi
08:50:42 gibi I never used git review. I like the full controll of git push <remote>
08:50:45 gibi <what>:refs/for/<branch>/topic
08:50:48 bauzas brinzhang: you have a local git remote on your git repo that's named 'gerrit'
08:50:54 bauzas git remote -v | grep gerrit
08:51:14 brinzhang_ bauzas: yeah, I know, it's in the project's git/config
08:51:24 bauzas correct
08:51:31 bauzas so you can basically test what you want
08:51:48 brinzhang_ I mean, Gerrit cannot know the merged conflict, if the patch doesnot merge
08:52:21 brinzhang_ in local I am easy to know which is conflict
08:52:30 brinzhang_ s/am/can
08:52:53 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in keypairs policies https://review.opendev.org/718619
08:53:04 bauzas maybe I misunderstand you
08:53:34 bauzas you mean that you can't predict that Zuul will tell you a merge conflict if there are concurrent patches coming by, if so yes I agree
08:53:40 brinzhang_ gibi: yes, git push gave by gerrit form patch's "Download" tag
08:54:13 brinzhang_ bauzas: yes, that's what I want to say
08:54:37 bauzas ... and nobody can :-)
08:55:01 bauzas that's what happens when you merge N changes at once without testing them each one by one
08:55:14 brinzhang_ bauzas, gibi: haha, thanks, I will check my question from sandbox test.
08:55:36 brinzhang_ bauzas: yes, agree
08:58:17 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in keypairs policy https://review.opendev.org/718621
08:58:38 bauzas gibi: okay so I'm confused
08:58:47 bauzas gibi: about https://review.opendev.org/#/c/718461/
08:59:01 bauzas tbh, I dropped attention yesterday evening about how things were going
08:59:59 gibi bauzas: we found yesterday that keys like trait:CUSTOM_* is not accepted
09:00:13 bauzas that, I understood :)
09:00:21 gibi and also found out that placement is more strict about trait names and resource class names than nova
09:00:44 gibi I think this is the two change in that patch
09:01:59 kashyap sean-k-mooney: stephenfin: Can you remind me again: Nova doesn't yet support vCPU hot unplug, yeah?
09:02:08 openstackgerrit Kevin Zhao proposed openstack/nova master: fix scsi disk unit number of the attaching volume when cdrom bus is scsi https://review.opendev.org/712607
09:02:22 stephenfin kashyap: correct
09:02:45 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing keypairs policies https://review.opendev.org/718604
09:03:03 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in keypairs https://review.opendev.org/718609
09:03:14 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in keypairs policies https://review.opendev.org/718619
09:03:26 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in keypairs policy https://review.opendev.org/718621
09:03:46 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Allow custom traits https://review.opendev.org/718461
09:03:50 kashyap stephenfin: Thx
09:04:23 kashyap And we do support I/O throttling? IIRC, we do have the I/O limit settings
09:04:40 stephenfin yes, though I don't know how well they work since testing is light
09:04:49 kashyap Yep; read_bytes_sec/write_bytes_sec
09:05:06 kashyap stephenfin: Oh, that rings a faint bell where you were traiging a bug on it
09:05:12 kashyap s/on it/about it/
09:05:32 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-evacuate policies https://review.opendev.org/708237
09:06:33 brinzhang stephenfin: can you explain why we add default=None, and not add for the --no-config-drive and --no-delete-on-termination?
09:06:45 brinzhang stephenfin: thanks for +W
09:06:51 kashyap Another one: no memory hotplug either, yeah?
09:07:38 brinzhang stephenfin: https://review.opendev.org/#/c/712651/19/novaclient/v2/shell.py@2741 and https://review.opendev.org/#/c/718349/4/novaclient/v2/shell.py@1551
09:08:01 stephenfin brinzhang: It's not necessary. The default will be set by '--config-drive' if it's not specified, and will be overridden by '--no-config-drive' if necessary
09:09:05 brinzhang controlled by "group"?
09:10:17 stephenfin Yeah, group is our own invention. It's essentially an alias for dest that also implies that we should add opts sharing the same value to a mutually exclusive group. See [1]
09:10:39 stephenfin [1] https://review.opendev.org/#/c/718349/4/novaclient/shell.py
09:10:44 stephenfin kashyap: correct
09:11:22 kashyap stephenfin: Thx; I'm answering a doc writer's questions. Hence the questions here
09:14:55 gibi sh*t https://review.opendev.org/#/c/716222/ got double hit by https://bugs.launchpad.net/nova/+bug/1823251 the gate queue will reset :/
09:14:57 openstack Launchpad bug 1823251 in OpenStack Compute (nova) "Spike in TestNovaMigrationsMySQL.test_walk_versions/test_innodb_tables failures since April 1 2019 on limestone-regionone" [High,Confirmed]
09:15:14 brinzhang stephenfin: yeah, I looked the group, got it, thanks
09:16:12 lyarwood gibi: time to reintroduce https://review.opendev.org/#/c/683009/ ?
09:16:58 gibi lyarwood: yeah. I think I will push that again
09:18:24 bauzas gibi: FWIW, I work tomorrow, I can fast-approve any change that was +W today
09:18:34 bauzas in case we got hit by the gate
09:18:56 gibi bauzas: thanks. I will rely on your power
09:19:19 bauzas gibi: the only problem is that I could miss any change, so please CC on the ones you'd like to see
09:19:23 bauzas CC me*
09:19:31 bauzas I can still ask gerrit to find me all +Wd tho

Earlier   Later