| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-25 | |||
| 18:51:45 | edmondsw | fair | |
| 18:52:02 | edmondsw | dansmith you were there, but didn't say anything :) | |
| 18:52:08 | mriedem | also, i'd say we're at the 4pm early bird special hour | |
| 18:52:16 | mriedem | aka jaypipes' dinner time | |
| 18:52:21 | dansmith | edmondsw: any words written down to validate that | |
| 18:52:25 | dansmith | as a formal decision? | |
| 18:52:48 | edmondsw | mriedem this was slated for Queens, only moved to Rocky because it wasn't reviewed in time | |
| 18:52:58 | mriedem | L315 https://etherpad.openstack.org/p/nova-ptg-queens | |
| 18:52:59 | smcginnis | The cinder video recordings have come in handy on more than one occasion for things like this. | |
| 18:53:19 | mriedem | "CI would not be running with this because CI with FC is hard." | |
| 18:53:25 | edmondsw | dansmith I think this was called out in the approved spec, I'll go double check | |
| 18:54:04 | mriedem | i'm kind of hurt that i didn't get any kudos for the jay + FL burn | |
| 18:54:28 | smcginnis | I laughed. | |
| 18:54:39 | edleafe | *All* of IBM's e's?? [t 2CNr] | |
| 18:54:39 | purplerbot | <mriedem> let it be known i am getting it from all the IBM e's now [2018-04-25 18:45:19.088382] [n 2CNr] | |
| 18:54:53 | edleafe | mriedem: I've been behaving | |
| 18:54:54 | mriedem | edleafe: oh sorry | |
| 18:55:05 | mriedem | IBM (power) e's | |
| 18:55:25 | jaypipes | mriedem: :) | |
| 18:55:31 | edleafe | mriedem: yeah, I'm not that POWERful at IBM | |
| 18:56:13 | mriedem | edmondsw: anyway, i'll defer to melwitt on the CI situation | |
| 18:56:24 | mriedem | i'm not blocking, but not happy about it either | |
| 18:56:38 | edmondsw | mriedem honestly, I'm not happy about it myself | |
| 18:57:09 | mriedem | i'd be happy to be unhappy together | |
| 18:57:10 | edmondsw | and I will do what I can to see what we can do there | |
| 18:57:14 | edmondsw | wfm :) | |
| 18:59:19 | openstackgerrit | Zack Cornelius proposed openstack/nova-specs master: Libvirt file backed memory https://review.openstack.org/563704 | |
| 18:59:47 | edmondsw | dansmith doesn't look like the approved queens spec called out lack of CI for vSCSI. I know we discussed at the PTG before the spec was approved, but I think it was approved pretty quickly there before we updated it to call that out | |
| 19:00:27 | dansmith | ack | |
| 19:01:14 | mriedem | might it be possible to have an on-demand job for powervm+volume stuff? | |
| 19:01:23 | mriedem | then you can run it on patches when asked at least as a bridge to something more automated? | |
| 19:02:11 | cdent | efried[m]: ping from nova? | |
| 19:02:20 | mriedem | lbragstad: for the policy in code goal, did you have any nice 7 step guides for teams to do that with the latest oslo.policy tricks? or for placement policy-in-code, should i just continue to cludge the existing nova policy code for placement? | |
| 19:02:47 | edmondsw | mriedem worth looking into, sure | |
| 19:02:49 | lbragstad | i laid out some of the steps in the goal | |
| 19:03:02 | lbragstad | but if they aren't clear i can work on another document | |
| 19:03:14 | lbragstad | or clean those up, because that's probably pretty important | |
| 19:03:18 | efried | cdent: Nothing. | |
| 19:03:43 | lbragstad | all i see is the completion criteria https://governance.openstack.org/tc/goals/queens/policy-in-code.html#completion-criteria | |
| 19:04:17 | mriedem | lbragstad: yeah just found that | |
| 19:04:41 | mriedem | lbragstad: np, i'll go back to my old patch and see what i was doing wrong | |
| 19:05:23 | lbragstad | mriedem: i can try and propose a patch to oslo.policy that walks through how start fresh with using those objects if that would be helpful | |
| 19:05:42 | mriedem | up to you | |
| 19:06:16 | mriedem | i think we (nova) have to decide some stuff like would we have /etc/nova/policy.yaml include placement stuff, or /etc/placement/policy.yaml | |
| 19:06:21 | mriedem | i'd prefer the latter | |
| 19:06:26 | mriedem | but not sure how possible that is when the code is in the same repo | |
| 19:06:45 | mriedem | should just be extra data files for the setup.cfg so i don't know why it would be a problem | |
| 19:10:15 | edmondsw | mriedem separate policy.yaml for placement should be doable | |
| 19:10:24 | melwitt | edmondsw, mriedem, dansmith: I think the volume tests should be enabled in CI. is there some reason they aren't? | |
| 19:10:37 | dansmith | melwitt: "it's hard" | |
| 19:10:58 | dansmith | I'll also say I think that tempest validation being disabled is a problem, | |
| 19:11:07 | dansmith | related but not strictly to volume CI | |
| 19:11:12 | melwitt | the ssh validation? that should be enabled too | |
| 19:11:16 | dansmith | no idea how that got ignored | |
| 19:11:20 | dansmith | yeah, ssh validation | |
| 19:11:41 | lbragstad | mriedem: i think there is a way to split up policy data across multiple configs | |
| 19:11:44 | dansmith | without ssh validation, I think working CI is mostly a charade | |
| 19:12:03 | dansmith | "oh look, we can create instances that may or may not be steaming piles of unworking sh*t" | |
| 19:12:26 | edmondsw | melwitt with our current hardware, it just wouldn't work. If we can get more hardware, there are still some technical challenges with the way that hardware works (limited simultaneous connections, how to detect and cleanup stale volumes from previous runs) | |
| 19:12:43 | lbragstad | mriedem: https://bugs.launchpad.net/oslo.policy/+bug/1766953 | |
| 19:12:43 | openstack | Launchpad bug 1766953 in oslo.policy "Lacking documentation for new projects using oslo.policy" [Undecided,New] | |
| 19:12:52 | melwitt | with regard to a virt driver, yeah, lack of ssh validation is just testing that nothing prevents the instance from being built, not whether the instance actually works | |
| 19:13:10 | mriedem | edmondsw: "limited simultaneous connections" can be solved with (1) run tempest tests in serial and (2) limit the set of tests you run and (3) make it an on-demand job to start | |
| 19:13:33 | edmondsw | mriedem I meant across simultaneous CI runs | |
| 19:13:51 | dansmith | nova is about self-service dynamic resources.. if you can't do that, then, uh... | |
| 19:13:53 | edmondsw | but yeah, on-demand job would address that | |
| 19:14:21 | edmondsw | going into a mtg... | |
| 19:14:38 | openstackgerrit | Mohammed Naser proposed openstack/nova stable/pike: Make sure that we have usable input for graphical console https://review.openstack.org/564320 | |
| 19:14:39 | mriedem | lbragstad: thanks | |
| 19:15:55 | melwitt | yeah, I guess I don't think we should have something in-tree that doesn't have CI covering its basic functionality | |
| 19:18:21 | edmondsw | so esberglu I think we need to rebase the rest of the PowerVM commits, moving vSCSI to the end of the series, so this doesn't block everything | |
| 19:18:27 | edmondsw | efried ^ | |
| 19:18:40 | dansmith | melwitt: agree | |
| 19:19:11 | edmondsw | esberglu and we need to start working on an on-demand CI job for testing vSCSI FC | |
| 19:19:27 | esberglu | edmondsw: ok | |
| 19:19:38 | lbragstad | jaypipes: re the oslo.context stuff you reviewed - https://review.openstack.org/#/c/564072/ should make that easier for nova to consume | |
| 19:20:09 | melwitt | I think y'all also need to get the CI running with [validation]run_validation = True in tempest.conf, unrelated to the volumes stuff | |
| 19:22:31 | edmondsw | melwitt I'm not sure we can. It will take minutes, probably close to 10, for the VM to ping. | |
| 19:23:13 | melwitt | :\ | |
| 19:23:17 | edmondsw | yeah | |
| 19:23:41 | esberglu | edmondsw: melwitt: Yeah this is something we've discussed for CI many times, but the runtimes will explode | |
| 19:23:55 | dansmith | edmondsw: minutes to bring up an instance to pingable state? | |
| 19:24:05 | edmondsw | dansmith yes | |
| 19:24:21 | dansmith | edmondsw: how is that useful for an elastic sort of situation? :) | |
| 19:25:21 | edmondsw | to Power customers, 10 minutes sounds very fast :) | |
| 19:25:41 | dansmith | edmondsw: hah, yeah, I know about power, remember, but doesn't stop me from making fun | |
| 19:25:50 | edmondsw | sure :) | |
| 19:25:50 | dansmith | especially in an "is this relevant at all" sort of situation | |
| 19:26:04 | edmondsw | again, I don't like it, but... | |
| 19:26:25 | mriedem | again, you could have a separate job that just runs something like scenario tests in serial | |
| 19:26:35 | edmondsw | fair | |
| 19:26:36 | mriedem | i don't think the scenario tests even use the run_validation flag | |
| 19:26:43 | mriedem | they just assume that you can ssh into the guest | |
| 19:26:51 | mriedem | otherwise they aren't useful scenarios | |
| 19:27:02 | edmondsw | I don't know that we've considered on-demand CI jobs before | |
| 19:27:15 | mriedem | the scenario-based one might not need to be on-demand | |
| 19:27:37 | mriedem | you'd have to see which tests make sense, and if you only run like 6 tests, then it's not bad | |
| 19:27:47 | edmondsw | mriedem I'm not quite following... what scenario do you have in mind? | |
| 19:28:00 | mriedem | https://github.com/openstack/tempest/tree/master/tempest/scenario | |
| 19:28:03 | melwitt | this is the basic functionality scenario test that verifies ssh and config drive https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py#L51 | |