| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-01 | |||
| 20:53:54 | artom | Dammit, http://www.checkmyprivilege.com/ is gone | |
| 21:02:02 | openstackgerrit | Artom Lifshitz proposed openstack/python-novaclient master: Error out if nic auto or none are not alone https://review.openstack.org/470000 | |
| 21:32:04 | mriedem | cfriesen_: never fear, i'm going through your instance flavors api change | |
| 21:48:42 | mriedem | dansmith: cfriesen_: dhellmann fixed the missing renos issue https://review.openstack.org/#/c/470023/ | |
| 21:49:15 | mriedem | just in time for everyone and their dog to be moving off mitaka | |
| 21:49:23 | mriedem | except penick | |
| 21:57:30 | mriedem | cfriesen_: reviewed | |
| 21:57:32 | mriedem | in great detail | |
| 22:03:16 | cfriesen_ | mriedem: thanks, will go check it out | |
| 22:03:56 | cfriesen_ | geez, could you add more stuff? | |
| 22:06:50 | mriedem | i don't think so | |
| 22:12:42 | cfriesen_ | mriedem: for the one that will be max_version 2.46, do you want it named as flavor_id_2_46? | |
| 22:14:33 | mriedem | looking | |
| 22:15:00 | cfriesen_ | and for "flavor_links" which is unversioned, did you want me to add a _2_46 version for clarity? | |
| 22:15:35 | mriedem | so flavor_id_body_2 -> flavor_id_body_2_46? | |
| 22:15:38 | cfriesen_ | that way all the sub-fields of flavor would be versioned | |
| 22:15:42 | cfriesen_ | yes | |
| 22:15:44 | mriedem | i think that's probably fine | |
| 22:16:02 | mriedem | i think it makes more sense than incrementing | |
| 22:16:46 | cfriesen_ | what about totally new ones like "flavor_original_name" ? add 2_47 or leave unversioned? | |
| 22:17:00 | cfriesen_ | it'd be the only unversioned field | |
| 22:17:00 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/470037 | |
| 22:17:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Connecting Nova to DRBD storage nodes directly https://review.openstack.org/256292 | |
| 22:17:35 | mriedem | melwitt: fixed the link ^ | |
| 22:17:45 | mriedem | cfriesen_: i think you can leave it unversioned if it's not a duplicate | |
| 22:17:50 | mriedem | i'm good either way on those | |
| 22:17:52 | cfriesen_ | kay | |
| 22:21:12 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/469581 | |
| 23:22:45 | melwitt | mriedem: coolness | |
| 23:27:26 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Avoid forcing translation on logging calls https://review.openstack.org/413876 | |
| 23:28:00 | melwitt | mriedem: +2. also wanted to show you this, easy two patch series for the PCIWeigher in scheduler, if you wanted to close out another blueprint https://review.openstack.org/#/c/379524/ cfriesen, you might also be interested in reviewing | |
| 23:28:03 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Use PCIAddressField in oslo.versionedobjects https://review.openstack.org/466201 | |
| 23:41:17 | openstackgerrit | Artom Lifshitz proposed openstack/python-novaclient master: Error out if nic auto or none are not alone https://review.openstack.org/470000 | |
| 23:43:18 | cfriesen_ | melwitt: it's on my review list, but stuff keeps coming up. | |
| 23:43:32 | melwitt | ack | |
| #openstack-nova - 2017-06-02 | |||
| 00:03:29 | openstackgerrit | John Griffith proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 00:17:09 | openstackgerrit | Artom Lifshitz proposed openstack/python-novaclient master: Error out if nic auto or none are not alone https://review.openstack.org/470000 | |
| 00:25:26 | mriedem | melwitt: yeah i wanted cfriesen_ to review that first | |
| 00:27:32 | mriedem | i guess i can gander while i'm on a call tonight | |
| 00:27:36 | mriedem | a welcome distraction | |
| 00:29:59 | openstackgerrit | guang-yee proposed openstack/nova master: libvirt: Reconnect volumes and encryptors during a hard reboot https://review.openstack.org/400384 | |
| 00:33:26 | melwitt | heh | |
| 00:41:23 | openstackgerrit | Artom Lifshitz proposed openstack/python-novaclient master: Better handle key=value pair not being key=value https://review.openstack.org/469988 | |
| 00:59:07 | mriedem | melwitt: reviewed https://review.openstack.org/#/c/379524/ but i clearly don't understand how this works, or weighers for that matter | |
| 01:00:25 | melwitt | mriedem: oh, sorry about that :( | |
| 01:02:11 | melwitt | you're right that the weigher wants to favor hosts with fewer free PCI devices, packing like you said. it intends to leave room for possible future requests that actually need several devices at the same time | |
| 01:02:42 | melwitt | *several devices on the same host | |
| 01:05:12 | cfriesen_ | mriedem: you had suggested a functional test with non-empty extra-specs. I think that means adding extra-specs to one of the flavors used in the functional tests, no? | |
| 01:11:24 | mriedem | cfriesen_: or just create a new flavor for the test | |
| 01:11:37 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/470037 | |
| 01:11:40 | cfriesen_ | mriedem: yeah, was just looking at that | |
| 01:17:04 | cfriesen_ | mriedem: is there a way to make a new flavor without needing to add new template files? | |
| 01:17:35 | mriedem | cfriesen_: yeah there is an api client used in the non-api sample functional tests | |
| 01:18:19 | mriedem | cfriesen_: something like this https://github.com/openstack/nova/blob/master/nova/tests/functional/integrated_helpers.py#L171 ? | |
| 01:18:44 | melwitt | you can checkout this badass functional test I wrote for an example https://review.openstack.org/#/c/355091/8/nova/tests/functional/test_boot_from_volume.py@54 | |
| 01:19:22 | mriedem | cfriesen_: the api sample tests use that mixin i think https://github.com/openstack/nova/blob/master/nova/tests/functional/api_samples_test_base.py#L69 | |
| 01:19:34 | mriedem | yeah, so you can re-use that method | |
| 01:19:38 | mriedem | to create a new flavor with what you need in it | |
| 01:19:49 | mriedem | even extra specs | |
| 01:20:22 | mriedem | although...the flavor ref is in the api sample request, | |
| 01:20:32 | mriedem | so things might get weird with subs | |
| 01:20:50 | cfriesen_ | I'll play with it, I guess | |
| 01:21:29 | mriedem | or modify that helper method to allow passing in a flavorid you define, which is some hard-coded uuid in your tests | |
| 01:21:38 | mriedem | and put that flavorid in the request samples | |
| 01:21:40 | mriedem | something like that | |
| 01:22:25 | cfriesen_ | realistically it would probably make sense for one of the default flavors to have extra specs just to test other code paths | |
| 01:22:34 | mriedem | thing is you'd have to delete the flavor between test cases, or add a check to make sure you don't try to create it if it already exists | |
| 01:22:46 | mriedem | yeah maybe, there is a flavor fixture | |
| 01:23:01 | mriedem | https://github.com/openstack/nova/blob/master/nova/tests/fixtures.py#L619 | |
| 01:23:10 | mriedem | throw a new default flavor in that fixture maybe | |
| 01:23:14 | cfriesen_ | but I'm sure changing the fixtures would have wide ranging effects | |
| 01:23:18 | mriedem | note that could throw off other tests though | |
| 01:23:20 | mriedem | maybe | |
| 01:23:48 | mriedem | maybe do that in a separate change to see how big the change is | |
| 01:24:02 | mriedem | and then if it's not that bad, you do that separately, and then rebase your change on top of it to use that new flavor | |
| 01:24:14 | cfriesen_ | yeah, that'd be cleanest if it's not crazy | |
| 01:30:38 | openstackgerrit | Chris Friesen proposed openstack/nova master: add extra_specs to one flavor in test fixtures https://review.openstack.org/470076 | |
| 01:32:05 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Blacklist sphinx 1.6.1 and later https://review.openstack.org/470077 | |
| 01:38:38 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Blacklist sphinx 1.6.1 and later https://review.openstack.org/470077 | |
| 01:56:11 | cfriesen_ | I tried creating some extra-specs in api_sample_tests/test_servers.py and got a 403 response. I'm guessing the tests are not run as an admin user? | |
| 01:57:56 | cfriesen_ | looks like it, I added "ADMIN_API = True" and now I can do it | |
| 01:58:10 | melwitt | yeah, you need something like "self.admin_api = self.api_fixture.admin_api" in setUp() | |
| 02:00:12 | melwitt | cfriesen_: I dunno if you saw my earlier link to a test that creates flavors, to use as an example. it might help https://review.openstack.org/#/c/355091/8/nova/tests/functional/test_boot_from_volume.py | |
| 02:05:07 | cfriesen_ | melwitt: can you mix the integrated_helpers stuff with the api samples tests though? | |
| 02:05:39 | cfriesen_ | melwitt: I've got the flavor extra spec creation working, now just trying to fix up the template matching | |
| 02:09:26 | melwitt | cfriesen_: oh, I didn't realize you were working on a api sample test. maybe not, I'm not sure | |
| 02:09:40 | melwitt | sounds like you're through the woods already anyway | |
| 02:10:46 | cfriesen_ | melwitt: I think so. it'd be nicer if the template/result comparison gave an error messsage better than "Failed to match Template to Response: Values do not match:" | |
| 02:11:18 | melwitt | yeah. I've worked on api samples a few times and it was frustrating | |
| 02:12:14 | mriedem | cfriesen_: if you're creating a new flavor with a dynamic id/name each time then i think the api samples are going to be hard | |
| 02:12:29 | mriedem | b/c the nova/doc/api_samples have to have something hard-coded for the actual api-ref docs | |
| 02:12:37 | mriedem | they can't have like %(uuid)s | |
| 02:12:40 | cfriesen_ | mriedem: I'm just adding extra-specs to flavor 1 | |
| 02:12:53 | melwitt | if he's doing a new test he'll have new json that he can add the {uuid} matcher thing to, right? | |
| 02:13:10 | melwitt | oh | |
| 02:13:32 | cfriesen_ | or is that going to mess up other tests? | |
| 02:14:13 | cfriesen_ | If I have to make a new flavor I can do that, I think we can hardcode the flavor id | |
| 02:15:03 | cfriesen_ | all this just to put some extra-specs in the api sample | |
| 02:15:57 | melwitt | api samples, you just don't touch em | |
| 02:16:09 | melwitt | back away slowly | |