| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-21 | |||
| 17:37:35 | dane-fichter | johnthetubaguy: but there's no real reason other than the semantics of download() that all drivers can't support this | |
| 17:38:04 | dane-fichter | johnthetubguy: seems like we should just modify download() to take the instance or flavor object as well | |
| 17:38:09 | johnthetubaguy | dane-fichter: oh, yes, agreed with you, well not all drivers use that download() method, the ones that do can support it | |
| 17:38:35 | dane-fichter | johnthetubaguy: ohh was not aware of that | |
| 17:39:01 | sfinucan | sgordon: Done | |
| 17:39:30 | dane-fichter | johnthetubaguy: so we could probably do both things here; use driver capabilities to prevent unsupported drivers from booting trusted flavors | |
| 17:39:37 | johnthetubaguy | dane-fichter: xenapi has its own in hypervisor route, to avoid a double hop, because nova-compute doesn't run somewhere with access to the hypervisor disk | |
| 17:40:15 | johnthetubaguy | dane-fichter: yeah, sounds like we are talking slightly cross purposes in there, agreed with with doing both things | |
| 17:40:58 | johnthetubaguy | dane-fichter: honestly, lots of that detail we can leave till code review, its just a saw detail in the spec that didn't look quite right to me, if that makes sense | |
| 17:41:37 | dane-fichter | johnthetubaguy: yeah. so maybe just tone down the detail in that implementation steps section? | |
| 17:42:08 | dane-fichter | johnthetubaguy: i'll definitely specify the driver capabilities wrinkle | |
| 17:42:41 | johnthetubaguy | dane-fichter: yeah, I think we need to add how to deal with "strange" virt drivers, but yeah the method calls and where the code exactly lives probable best left till later | |
| 17:43:49 | johnthetubaguy | s/probable/probably/ | |
| 17:44:44 | dane-fichter | johnthetubaguy: yes, agreed. thanks john | |
| 17:45:15 | johnthetubaguy | dane-fichter: no worries | |
| 18:11:26 | mriedem | sfinucan: i've got to update that bug fix patch, missed a couple tests | |
| 18:13:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: conditionally set script path for ethernet vif types https://review.openstack.org/448203 | |
| 18:13:03 | mriedem | sfinucan: here we go ^ | |
| 18:17:33 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in cells.py https://review.openstack.org/448224 | |
| 18:18:39 | openstackgerrit | Gábor Antal proposed openstack/nova master: Pre-add functional tests stub to notification testing https://review.openstack.org/448225 | |
| 18:22:31 | dane-fichter | mriedem: got a second to discuss the cursive change? | |
| 18:22:42 | dane-fichter | mriedem: this one https://review.openstack.org/#/c/351232/ | |
| 18:30:02 | mriedem | dane-fichter: yeah | |
| 18:34:15 | openstackgerrit | Gábor Antal proposed openstack/nova master: Pre-add functional tests stub to notification testing https://review.openstack.org/448225 | |
| 18:44:48 | mriedem | sdague: do you have an opinion on how to handle these tests? https://review.openstack.org/#/c/351232/11/nova/tests/unit/objects/test_fields.py | |
| 19:06:36 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: console https://review.openstack.org/409402 | |
| 19:08:32 | sdague | mriedem: I need a lot more context here | |
| 19:09:42 | mriedem | sdague: the signature_utils stuff is now in a library | |
| 19:09:49 | mriedem | used in nova and glance | |
| 19:10:04 | mriedem | we have versioned objects that use enum fields with values defined in that library now | |
| 19:10:31 | mriedem | we have tests in nova that check to make sure if you update the constants in signature_utils (now the library), we bump the enum lists in the versioned object, | |
| 19:10:37 | mriedem | that was all fine and dandy while it was all within nova, | |
| 19:11:11 | mriedem | but with the constants defined in a library now, it means if the library adds new constants, our unit tests will fail and requires a dance to get things working to use the library in upper-constraints | |
| 19:11:16 | sdague | ok, so don't you want to invert the iteration? | |
| 19:11:28 | mriedem | i left a comment in there about what i think the dance is, | |
| 19:11:30 | mriedem | if we leave things as-is | |
| 19:11:34 | mriedem | and get the constants from the library now | |
| 19:11:40 | sdague | so just test that the enum in Nova are all in in the signature utils lib ? | |
| 19:11:57 | mriedem | other way around, | |
| 19:12:09 | mriedem | the test makes sure that the constants defined in the lib are reflected in our enums, | |
| 19:12:13 | mriedem | which feed into ImageMetaProps | |
| 19:12:33 | sdague | mriedem: ok, I'm not sure why that's actually important to couple here | |
| 19:12:45 | mriedem | so if a new constant is added and released, we can't use that version of the library in upper-constraints until nova makes a change, before g-r is bumped, which is a bit odd | |
| 19:12:59 | sdague | mriedem: yeh, so, that's fine | |
| 19:12:59 | mriedem | i'm not sure it is either | |
| 19:13:08 | mriedem | that's just the way it was when it was all in tree | |
| 19:13:24 | sdague | the whole purpose of decoupling to a library is not to have lock step coupling with projects | |
| 19:13:27 | mriedem | i suppose to keep a reminder that if we support new hash methods and key types that our image meta properties object should also support those | |
| 19:13:34 | sdague | yep | |
| 19:13:45 | sdague | also, it's not like new hash methods just spring forth all the time | |
| 19:14:00 | mriedem | if the library adds new things now, and we don't keep our enums and versioned objects up to date, then i guess someone just has to do that when they actually want to use a new thing in the library | |
| 19:14:01 | sdague | they take years to a decade to proof out | |
| 19:14:05 | mriedem | yeah | |
| 19:14:22 | mriedem | so i'm also ok with just dropping the nova tests i think | |
| 19:14:28 | sdague | so the fact that you add to the lib, then add to the lib consumers, seems fine | |
| 19:15:10 | mriedem | ok so pro-drop the tests and coupling | |
| 19:15:26 | mriedem | that works for me, i just didn't like thinking this through in a vacuum | |
| 19:22:50 | mriedem | dane-fichter: ^ replied in the change too | |
| 19:30:11 | dane-fichter | mriedem: I see. Just read the discussion w sdague too. sounds good. | |
| 19:45:55 | mriedem | gcb: can't we do this now? https://github.com/openstack/nova/blob/master/tox.ini#L70 | |
| 19:46:05 | mriedem | the functional-py35 job is gating on nova | |
| 19:46:17 | mriedem | i'm not sure how basepython would work with that though, or if you just omit it | |
| 19:46:38 | mriedem | we would also have to change the job defintions in project-config if we combined those two jobs | |
| 20:05:26 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in cells_scheduler.py https://review.openstack.org/448260 | |
| 20:08:22 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Tests: remove .testrepository/times.dbm in tox.ini (functional) https://review.openstack.org/448266 | |
| 20:10:50 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/446674 | |
| 20:11:45 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in certificates.py https://review.openstack.org/448267 | |
| 20:13:50 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in cells.py https://review.openstack.org/448224 | |
| 20:17:14 | mriedem | sdague: are you going to be submitting a forum session proposal for limits in keystone? | |
| 20:30:01 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in cloudpipe.py https://review.openstack.org/448271 | |
| 20:33:35 | sdague | mriedem: I suppose, I'm still a little confused on content for the forum | |
| 20:33:49 | mriedem | you and me both, | |
| 20:33:59 | mriedem | but it sounds like we start submitting abstracts and then the TC and UC vote on them | |
| 20:34:31 | mriedem | http://lists.openstack.org/pipermail/user-committee/2017-March/001856.html | |
| 20:34:38 | mriedem | sessions are proposed here http://forumtopics.openstack.org/ | |
| 20:35:25 | dansmith | I'm totally confused | |
| 20:35:35 | dansmith | I put some stuff in an etherpad which was originally requested | |
| 20:35:47 | mriedem | i think the brainstorming etherpads were for project teams to agree on what to submit to http://forumtopics.openstack.org/ | |
| 20:36:06 | mriedem | "Starting today, our submission tool is open for you to submit abstracts for the most popular sessions that came out of your brainstorming. *Please note that the etherpads are not being pulled into the submission tool and discussion around which sessions to submit are encouraged.*" | |
| 20:36:14 | dansmith | ah okay | |
| 20:36:15 | dansmith | confusing | |
| 20:36:24 | mriedem | so we'll have one for cells, one for placement and one for limits | |
| 20:36:26 | mriedem | at least | |
| 20:36:39 | mriedem | "We are looking for a good mix of project-specific, cross-project or strategic/whole-of-community discussions, and *sessions that emphasize collaboration between users and developers are most welcome!*" | |
| 20:36:42 | dansmith | mriedem: are you going to do those to avoid overlap or should I put one in there? | |
| 20:36:45 | mriedem | i think those 3 fall into that category | |
| 20:36:48 | johnthetubaguy | I think brainstorming turned into formal submission | |
| 20:36:51 | johnthetubaguy | but I got confused too | |
| 20:36:55 | bauzas | not sure I understand how the Forum works, honestly | |
| 20:37:05 | mriedem | ha, it was so quiet in here for the last several hours | |
| 20:37:11 | mriedem | you were all just lurking | |
| 20:37:13 | bauzas | AFAICU, there are some sessions for newcomers too | |
| 20:37:17 | mriedem | dansmith: submit one for cells | |
| 20:37:22 | dansmith | okay | |
| 20:37:22 | mriedem | bauzas: that's separate | |
| 20:37:26 | mriedem | bauzas: i think anyway | |
| 20:37:34 | mriedem | diablo_rojo is coordinating that | |
| 20:37:42 | bauzas | okay | |
| 20:37:49 | mriedem | but she's not on irc so idk for sure | |
| 20:37:55 | dansmith | mriedem: and this is for user/op interaction, or review of the progress and planning for the rest of the cycle or what? | |