| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-12 | |||
| 13:00:34 | aspiers | our partnership with AMD goes way back | |
| 13:00:38 | leakypipes | ack | |
| 13:00:51 | aspiers | IIRC we were the first enterprise Linux to support AMD, or something like that | |
| 13:01:08 | aspiers | mind you, we're obviously very close with Intel too | |
| 13:01:25 | leakypipes | gotcha | |
| 13:04:21 | mriedem | well, i guess we have to decide if the volume_type support when creating a server should be the same as cinder's volume create api https://review.openstack.org/#/c/606398/ and allow passing volume_type='' or volume_type=None, or restrict that in the compute API | |
| 13:04:30 | mriedem | so that if you pass a volume_type, it has to be non-null and minLength: 1 | |
| 13:05:10 | mriedem | i'm personally fine keeping parity with cinder's API since people really just want the proxy here | |
| 13:07:41 | leakypipes | mriedem: how about --volume-type=force:True? That would mesh well with our long tradition of force APIs. | |
| 13:08:04 | leakypipes | mriedem: you could even add a --volume-type=force:None to make things super clear. | |
| 13:08:13 | mriedem | i would like it to pass it over flavor extra spec myself, | |
| 13:08:16 | mriedem | but we don't all get what we want | |
| 13:08:39 | leakypipes | mriedem: scheduler hint for volume type --hint force-volume-type=None | |
| 13:08:42 | mriedem | or encoded scheduler hitn | |
| 13:08:43 | mriedem | *hint | |
| 13:08:46 | mriedem | yes | |
| 13:08:48 | leakypipes | mriedem: beat you to it. | |
| 13:10:54 | giblet | :) | |
| 13:13:43 | mordred | leakypipes: looking | |
| 13:16:21 | leakypipes | mordred: thanks man. it was mriedem who also wanted your opinion on that, which I concurred with. | |
| 13:16:56 | mordred | leakypipes: I believe the patch looks fine - and I'm happy to see people are excited about the split-loggers option :) | |
| 13:18:25 | mriedem | ? https://review.openstack.org/#/c/581218/ ? | |
| 13:20:40 | leakypipes | mordred: what about sean-k-mooney's first comment here? https://review.openstack.org/#/c/581218/5/novaclient/v2/client.py | |
| 13:20:47 | leakypipes | mordred: is that a concern? | |
| 13:21:20 | mriedem | jackding: you know your reboot/rebuild check the network for unbound ports patch? | |
| 13:21:23 | leakypipes | mriedem: yes, that one. you had commented on there: "-1 for the missing lower-constraints bump, but I'd also like to see Monty +1 this before we merge it since I'm not really following all of this." | |
| 13:21:30 | mriedem | that's checking the ports right after we refreshed them from neutron, | |
| 13:21:35 | mriedem | can we avoid the list_ports in your check method? | |
| 13:21:39 | mriedem | and just use the instance.info_cache? | |
| 13:21:44 | mriedem | that would help some of my concern | |
| 13:21:55 | mriedem | leakypipes: yar | |
| 13:22:05 | mriedem | if you want split logs, pass a scheduler hint | |
| 13:22:07 | leakypipes | mriedem: aye, matey. | |
| 13:22:19 | leakypipes | mriedem: lol. thx moleman. | |
| 13:22:34 | leakypipes | there he is! | |
| 13:23:12 | hansmoleman | https://deadhomersociety.files.wordpress.com/2016/11/thisisaknife.gif?w=655 | |
| 13:24:27 | hansmoleman | gmann: do you have a patch to cap max microversions for tempest in devstack for rocky yet? | |
| 13:25:30 | hansmoleman | nope, i'll do that | |
| 13:30:17 | openstackgerrit | sean mooney proposed openstack/nova master: harden placement init under wsgi https://review.openstack.org/610034 | |
| 13:33:35 | sean-k-mooney | ^ that may be dumb but its my attempt to fix part of a downstream bug in triplo that i dont have an enviornment to reproduce and or time to reporduce. | |
| 13:34:01 | hansmoleman | comments inline | |
| 13:34:09 | hansmoleman | efried: what's the process now for placement bug fixes? | |
| 13:34:15 | hansmoleman | fix in nova and cherry pick to placement or vice versa? | |
| 13:35:39 | sean-k-mooney | oh right placement is moving... | |
| 13:39:29 | mordred | leakypipes, hansmoleman: +1 left - I agree with sean-k-mooney's followup comment | |
| 13:40:56 | PapaOurs | hansmoleman: AFAIUC, we need two changes | |
| 13:41:11 | PapaOurs | hansmoleman: and just waiting for the placement one to be merged before merging the nova one | |
| 13:41:16 | PapaOurs | but not Depends-On | |
| 13:42:00 | finucannot | hansmoleman: What would it cost me to get you to look at https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens+topic:bug/1746393 again? | |
| 13:42:30 | finucannot | hansmoleman: It's not something I'm going to be able to test with the Intel NFV CI but I did manually verify it | |
| 13:45:23 | PapaOurs | does someone remember the link for querying all the OpenStack project repos ? | |
| 13:46:17 | hansmoleman | codesearch.openstack.org | |
| 13:46:57 | PapaOurs | hansmoleman: <3 | |
| 13:47:24 | hansmoleman | finucannot: how far back to plan on trying to get those backports? has that code just always been broken? | |
| 13:47:33 | hansmoleman | that stack seems extremely risky to me | |
| 13:47:40 | hansmoleman | especially when we have 0 CI | |
| 13:49:51 | hansmoleman | s/to plan/do you plan/ | |
| 13:50:00 | finucannot | hansmoleman: Ideally back to when support for emulator threads was first added (Ocata) but Ocata is em now and I haven't even looked at the practicality of Pike. Queens would be good enough | |
| 13:50:33 | finucannot | Plus, Pike is just security/data loss bugs now anyway, right? | |
| 13:50:50 | hansmoleman | no | |
| 13:50:57 | hansmoleman | EM means we no longer have phases like that | |
| 13:51:29 | hansmoleman | https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases | |
| 13:51:37 | finucannot | The more you know | |
| 13:52:02 | sean-k-mooney | leakypipes: ya i proably should have submitted it against placement. | |
| 13:52:02 | finucannot | But yeah, given how specific this is, whatever risk there is is going limited to select use cases | |
| 13:52:30 | sean-k-mooney | leakypipes: ill abandon after the ci results are in i mainly pushed to make sure this did not make anything else explode | |
| 13:52:59 | finucannot | That said, I have no idea how else to mitigate that risk besides the unit tests, manual testing that's already been done and downstream QE we'll be doing for this | |
| 13:54:22 | leakypipes | sean-k-mooney: get with cdent in #openstack-placement since he's got a patch series already that is cleaning up the placement DB stuff. | |
| 13:54:42 | leakypipes | sean-k-mooney: Chris isn't here atm, but just grab him whenevs | |
| 13:56:22 | sean-k-mooney | leakypipes: sure. im likely not going to be working on this till next week. im in munich for new heir orentation from sunday to wednesday so i wont get much done until thrusday | |
| 13:57:10 | leakypipes | ack, no worries. | |
| 13:57:26 | leakypipes | sean-k-mooney: btw, is "new heir orentation" something to do with the royal family? | |
| 13:57:44 | leakypipes | :P | |
| 13:57:44 | sean-k-mooney | also apparently i joinded redhat 90days ago as of monday. | |
| 13:57:53 | leakypipes | sean-k-mooney: congrats! :) | |
| 13:58:54 | PapaOurs | sean-k-mooney: I'm sure you'll love sales talks | |
| 13:59:24 | sean-k-mooney | PapaOurs: apparently we are not ment to bring our laptops to the 2 days of training... | |
| 13:59:41 | PapaOurs | sean-k-mooney: tbh I don't remember mine | |
| 13:59:44 | sean-k-mooney | also i miss octoberfest in munich by a week | |
| 13:59:59 | PapaOurs | I mean, whether I used my laptop | |
| 14:00:10 | PapaOurs | but you'll get a free fedora | |
| 14:00:18 | PapaOurs | hum | |
| 14:00:25 | PapaOurs | looks like we're discussing corp here | |
| 14:00:28 | PapaOurs | shit | |
| 14:00:49 | PapaOurs | fortunately, I'm hidden behind my nick | |
| 14:00:49 | sean-k-mooney | :) | |
| 14:07:04 | fried_rice | hansmoleman: Same fix (as far as possible) with same change-id in both nova and placement | |
| 14:08:08 | melwitt | ||
| 14:10:58 | hansmoleman | fried_rice: does order of repos matter? | |
| 14:11:09 | hansmoleman | placement first so it's not lost after the extraction? | |
| 14:11:28 | fried_rice | I don't think so | |
| 14:11:59 | fried_rice | Like, propose it to both at the same time, but I don't think it matters if one merges first as long as they both merge. | |
| 14:12:47 | hansmoleman | that's kind of weird | |
| 14:12:55 | hansmoleman | if one merges and the other has changes | |
| 14:12:59 | hansmoleman | i think of it like backports | |
| 14:13:12 | hansmoleman | you want to start in the clean target first and then cherry pick (backport) to nova | |
| 14:13:26 | hansmoleman | but what do i know | |
| 14:16:21 | hansmoleman | SteelyDan: re our conversation the other day about attaching volumes while resized, apparently it's fine once you revert, the volume attached while the server is in VERIFY_RESIZE state continues to be attached when you revert | |
| 14:16:30 | hansmoleman | now, i'm using the fake driver in devstack so i can have 2 computes on a single node, | |
| 14:16:42 | hansmoleman | so i'm not sure that attached volume is actually still in the guest... | |