| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-04-25 | |||
| 13:09:01 | kashyap | I first dimissed it as cheap plastic crap; but it's been my daily driver for a couple of years | |
| 13:09:44 | gibi | it is on my list too but now your recommendation boosted it up on the list :L) | |
| 13:10:38 | kashyap | gibi: It's like French Press, but without the soot at the bottom | |
| 13:11:03 | bauzas | fwiw, I love my Mignifica S coffee machine :) | |
| 13:11:15 | kashyap | gibi: A single AeroPress in a cafe costs about 5 euros here! If I buy one. In 10 days the device will start paying for itself! | |
| 13:11:19 | kashyap | :) | |
| 13:11:24 | bauzas | Magnifica sorry | |
| 13:11:26 | gibi | I talked the barista in the coffee shop at the corner they do it with soaking during the night | |
| 13:11:43 | kashyap | gibi: Yeah, that's the "real" cold brew, indeed | |
| 13:12:06 | kashyap | I only make hot-brew w/ AeroPress, but cold is also possible, as the instructions point it out | |
| 13:12:56 | gibi | kashyap: totally true about the cost of shop coffee. I rearly visit the shop. I have my bialetti for mokka | |
| 13:13:00 | bauzas | I can do cold brew with my machine... I just need to wait for 10 mins after creating a coffee :p | |
| 13:13:14 | kashyap | LOL, it's not the same as overnight soaking | |
| 13:13:38 | bauzas | I know | |
| 13:13:48 | bauzas | but, | |
| 13:13:52 | kashyap | gibi: I work a lot from coffee shops (to beat the cabin fever) ... and probably spend more than I should on coffees. | |
| 13:13:58 | gibi | bauzas: you can try waiting 12 hours after you brew with a machine :) | |
| 13:13:58 | bauzas | I prefer to wait 12 hours for bbq :) | |
| 13:15:09 | gibi | kashyap: btw here a good cold brew costs ~2.5 EUR, but still :D | |
| 13:17:21 | artom__ | gibi, ack, I saw the review email come in, cheers! | |
| 13:31:54 | bauzas | elodilles: you left me puzzled https://review.opendev.org/c/openstack/releases/+/837953 | |
| 13:37:50 | elodilles | bauzas: well, i heard in the past that unreleased .gitreview and TOX_CONSTRAINTS update patches caused problems in RH downstream. in general that is not worth to create a release (no change in package at all), but with a 'patch' version bump maybe it does not hurt | |
| 13:38:50 | bauzas | elodilles: honestly, we don't really care of stable/victoria :) | |
| 13:38:56 | bauzas | we = my employer | |
| 13:39:36 | bauzas | sean-k-mooney: already heard of this ^ ? | |
| 13:40:03 | sean-k-mooney | ooo does not care | |
| 13:41:30 | sean-k-mooney | elodilles: downstream we do override the .gitignore but i dont think it should break us | |
| 13:41:45 | sean-k-mooney | elodilles: if it did it would be trivial to fix so i would always do the right thing upstream | |
| 13:42:53 | elodilles | bauzas sean-k-mooney : ack, then i think they are good as they are :) | |
| 13:42:55 | sean-k-mooney | elodilles: i think we can safely merge the .gitreview change and _not_ release it then apply the EM tag based on the sha but if we want the EM tag to point to the last release that is also ok | |
| 13:43:31 | bauzas | sean-k-mooney: the patch is already merged | |
| 13:43:36 | elodilles | sean-k-mooney: *-em tags always tha *last* release from the branch | |
| 13:43:54 | bauzas | the question is, should we include it as part of the -em tag, that's it | |
| 13:44:10 | bauzas | as we can't release a package after, like elodilles said | |
| 13:45:05 | bauzas | while I don't care of the CI changes as elodilles noted, I'm a bit torn whether we should include the propre gitreview target in the last build | |
| 13:45:17 | bauzas | "build" rather with quotes | |
| 13:45:44 | elodilles | from package point of view they are not included (pypi, tarball) so the release would just be unnecessary fuss for package consumers | |
| 13:46:18 | sean-k-mooney | elodilles: right but teh way the em tag is ment to work is it is ment ot allow you to restore the branch | |
| 13:46:31 | sean-k-mooney | so the em tag shoudl be on the last patch in the stable branch | |
| 13:46:54 | bauzas | then we should include the gitreview patch | |
| 13:47:22 | elodilles | sean-k-mooney: well, no, that's the *-eol you mean i think :) | |
| 13:47:33 | sean-k-mooney | oh sorry you are right | |
| 13:47:38 | sean-k-mooney | i was thinking of eol | |
| 13:47:42 | sean-k-mooney | for em we are not removing the branch | |
| 13:47:49 | sean-k-mooney | then ya its fine as is | |
| 13:47:55 | sean-k-mooney | no need to do another release | |
| 13:48:06 | sean-k-mooney | bauzas: do you agree? | |
| 13:48:56 | bauzas | hmmmm | |
| 13:49:18 | bauzas | I'm not *that* opiniated, I just want to be convinced | |
| 13:49:25 | bauzas | what's the purpose of the -em tag ? | |
| 13:49:46 | sean-k-mooney | really just to signal that no more releases will be made | |
| 13:52:40 | elodilles | yepp | |
| 13:54:48 | bauzas | that's my understanding | |
| 13:55:08 | bauzas | now, looking at https://review.opendev.org/q/project:openstack/python-novaclient+branch:stable/victoria | |
| 13:55:17 | bauzas | we only have 2 patches in the branch :) | |
| 13:55:26 | bauzas | one isn't required | |
| 13:55:38 | bauzas | the other one just updates the gitreview target | |
| 14:01:15 | elodilles | yepp, those are not part of the packages (even if we tag and release them) | |
| 14:07:34 | bauzas | elodilles: OK, then I'll change my vote | |
| 14:25:50 | opendevreview | Balazs Gibizer proposed openstack/nova master: Simulate bug 1969496 https://review.opendev.org/c/openstack/nova/+/838554 | |
| 14:25:51 | opendevreview | Balazs Gibizer proposed openstack/nova master: Allow claiming PCI PF if child VF is unavailable https://review.opendev.org/c/openstack/nova/+/838555 | |
| 14:26:54 | gibi | sean-k-mooney: finalized the fix ^^ | |
| 14:27:38 | opendevreview | Merged openstack/nova master: VMware: Split out VMwareAPISession https://review.opendev.org/c/openstack/nova/+/832156 | |
| 14:27:53 | sean-k-mooney | gibi: ack ill add that to my review list so for this week | |
| 14:28:01 | gibi | thanks! | |
| 14:28:47 | sean-k-mooney | ah nice you have all 3 parts. the repoduce, allowing it to claim and also fixing the inconsitent state | |
| 14:28:55 | gibi | yepp | |
| 14:36:50 | sean-k-mooney | gibi: is there a reason you did the simulation second in the series | |
| 14:37:19 | sean-k-mooney | i woudl have expected the startup patch to be last | |
| 14:37:33 | sean-k-mooney | so simulate, claim then start up | |
| 14:37:41 | sean-k-mooney | it works this way too just wondering | |
| 14:38:27 | gibi | the reason was that I started with teh cleanup path as it was easier to get to it. but no technical dependency so I can reorder if needed | |
| 14:39:51 | sean-k-mooney | no thats ok in principal once the start up check is merged you dont need the others | |
| 14:40:00 | sean-k-mooney | so that is why i was suggesting reordering | |
| 14:40:04 | sean-k-mooney | but i like having all 3 | |
| 14:40:27 | sean-k-mooney | (you would have to restart the agent to get this code hench the startup cleanup is enough) | |
| 14:42:02 | gibi | the current cleanup logic only works if the admin removes the VFs from the hypervisor first, then restart the agent. So if that removal (of the restart) is not possible then the claim-while-child-unavailable patch helps | |
| 14:42:14 | sean-k-mooney | ah you are right | |
| 14:42:35 | gibi | or I could create a wider cleanup logic that does not require the VF removal from the hypervisor | |
| 14:42:55 | gibi | just push the VF to available at startup | |
| 14:43:01 | gibi | regardles if it is removed or not | |
| 14:43:25 | gibi | and do this before the existing removed device cleanup logic | |
| 14:43:39 | gibi | we have full of options :) | |
| 14:45:35 | sean-k-mooney | im reviewing it now so unless others object lets keep this simple and go with what you have | |
| 14:45:48 | sean-k-mooney | we might want to do a larger cleanup later but this looks pretty backportable to me | |
| 14:46:33 | gibi | yepp it is pretty self contains now | |
| 14:46:50 | gibi | I will do the backports too | |
| 14:46:56 | gibi | once it lands on master | |
| 14:50:27 | opendevreview | Artom Lifshitz proposed openstack/nova master: Reproduce live migration rollback w/o multi port bindings error https://review.opendev.org/c/openstack/nova/+/839091 | |
| 14:50:28 | opendevreview | Artom Lifshitz proposed openstack/nova master: Fix LM rollback w/o multi port bindings extension https://review.opendev.org/c/openstack/nova/+/839227 | |
| 15:56:11 | opendevreview | Andre Aranha proposed openstack/nova master: Test setting the nova job to centos-9-stream https://review.opendev.org/c/openstack/nova/+/831844 | |
| 16:13:57 | sean-k-mooney | ah fips | |
| 16:14:02 | sean-k-mooney | i was like which job | |
| 16:30:41 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Run against performance.json patch https://review.opendev.org/c/openstack/nova/+/838934 | |
| 17:45:11 | melwitt | gmann: this is a small patch involving deprecation of [api] config option that you might be interested in reviewing https://review.opendev.org/c/openstack/nova/+/836253 | |
| 18:05:45 | gmann | melwitt: thanks, +A. lgtm. | |
| 18:13:54 | melwitt | thanks gmann | |
| 18:32:40 | opendevreview | Jakub Libosvar proposed openstack/os-vif master: Check for hybrid plugging in OVS https://review.opendev.org/c/openstack/os-vif/+/839102 | |
| 19:39:55 | opendevreview | Merged openstack/nova master: Deprecate [api] use_forwarded_for https://review.opendev.org/c/openstack/nova/+/836253 | |
| 23:15:07 | opendevreview | Ghanshyam proposed openstack/nova master: Move centos stream testing to centos-9-stream https://review.opendev.org/c/openstack/nova/+/839275 | |