| *** openstackgerrit has joined #openstack-interop | 04:29 | |
| openstackgerrit | Shamail Tahir proposed openstack/defcore: 2017.01 Scoring for Cinder https://review.openstack.org/408427 | 04:29 |
|---|---|---|
| openstackgerrit | Shamail Tahir proposed openstack/defcore: 2017.01 Scoring for Nova https://review.openstack.org/385781 | 04:39 |
| openstackgerrit | Shamail Tahir proposed openstack/defcore: 2017.01 Scoring for Nova https://review.openstack.org/385781 | 04:41 |
| *** pcaruana has joined #openstack-interop | 06:51 | |
| *** openstackgerrit has quit IRC | 12:33 | |
| *** tongli has joined #openstack-interop | 13:28 | |
| *** tongli has quit IRC | 15:14 | |
| *** shamail has joined #openstack-interop | 16:02 | |
| *** openstackgerrit has joined #openstack-interop | 16:06 | |
| openstackgerrit | Shamail Tahir proposed openstack/defcore: 2017.01 Scoring for Nova https://review.openstack.org/385781 | 16:06 |
| *** edmondsw_ has joined #openstack-interop | 16:45 | |
| *** edmondsw_ has quit IRC | 16:45 | |
| * shamail sneaks in | 17:00 | |
| markvoelker | So, couple of ideas on the cinder API transition: | 17:00 |
| eglute | o/ | 17:00 |
| markvoelker | 1.) We could leave things as they are in the patch now, which makes it clear to readers that v3 is a thing going forward | 17:01 |
| markvoelker | When the time comes that v3 has been in enough releases/etc, we could reorganize the capabilities to eliminate the version numbering | 17:01 |
| markvoelker | (this doesn't require another advisory cycle) | 17:02 |
| markvoelker | That would also buy some time for Cinder's plans for v2 to become more clear | 17:02 |
| markvoelker | (and the ecosystem's usage of v2 vs v3, which may effect other scoring criteria) | 17:03 |
| eglute | hogepodge what do you think | 17:03 |
| markvoelker | 2.) We could simply publish some sort of explicit note in the Guideline docs (might require a schema change) noting that v2 or v3 are acceptable, but v3 may be required somewhere down the line | 17:04 |
| *** shamail has left #openstack-interop | 17:05 | |
| *** shamail has joined #openstack-interop | 17:05 | |
| hogepodge | both sound good | 17:06 |
| eglute | hogepodge any one of those options would make your life easier when people submit their tests results? | 17:07 |
| markvoelker | Heh...I guess actually those aren't mutually exclusive options, either, come to think of it. =p | 17:08 |
| hogepodge | I was just thinking I like both together :-D | 17:08 |
| eglute | ok, then we will do both :D | 17:09 |
| catherineD | I am not sure what we mean by do both ... | 17:10 |
| catherineD | please take a look at https://review.openstack.org/#/c/408427/3/next.json line 2742 | 17:10 |
| catherineD | The capability is volumes-v2-create-delete | 17:10 |
| catherineD | but the test on line 2758 taking the path ov V2 | 17:11 |
| catherineD | tempest.api.volume.test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete | 17:11 |
| markvoelker | catherineD: right: basically that same test will pass either on v3 or v2 | 17:11 |
| hogepodge | catherineD: I see what you're saying, the patch still needs to be revised for clarity? | 17:11 |
| shamail | yeah, the same test can be used by both… there are no v3 specific tests yet | 17:12 |
| catherineD | in the past, tests would be the same but paths would be different | 17:12 |
| shamail | if we remove versions from the cinder capability names then users will not know about the transition at all (e.g. the resulting guideline would look the same as it does for v2 today but without mentioning v2) | 17:13 |
| catherineD | so I am not sure how these tests work for v3 need to dig in | 17:13 |
| shamail | We wouldn’t even make them advisory at that point, right? | 17:13 |
| catherineD | if the test and path are not distinguised among v2 and v3 .... should the capability name just remove the v2/v2 label? | 17:13 |
| catherineD | v2/v3 | 17:14 |
| catherineD | here is how the same test are with diff paths for v1/v2 | 17:15 |
| catherineD | tempest.api.volume.test_volumes_negative.VolumesV1NegativeTest.test_get_invalid_volume_id | 17:15 |
| shamail | I have to drop off for another meeting, i’ll review the comments on the patch with your decisions later today. Thanks. | 17:15 |
| markvoelker | To me, the distinction between v2 and v3 feels important from a user perspective. I want to know if my cloud supports microversions because at some point down the line that affects either the behavior of the cloud or the clients | 17:15 |
| catherineD | tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_get_invalid_volume_id | 17:15 |
| hogepodge | I need to step out for a few moments | 17:16 |
| catherineD | my point is ... I am not sure we know that the vendor support both v2 and v3 or which one ... if the test are the same for v2 and v3 | 17:16 |
| shamail | take care | 17:16 |
| *** shamail has quit IRC | 17:16 | |
| catherineD | if the same test passes both v2 and v3 .. | 17:17 |
| markvoelker | shamail: hogepoge: thanks gents, I'll be around later if you want to discuss further | 17:17 |
| markvoelker | catherineD: yeah, I think we're kind of using the capability name to say that v2 and v3 should both be supported, even if the tests are the same | 17:17 |
| markvoelker | catherineD: and keep in mind, that's a transitory thing: v3 wouldn't be required in 2017.01 (it's advisory) | 17:18 |
| markvoelker | If someone offers only v3 they'd technically still pass all the tests though, and functionally that cloud is probably interoperable with v2-only clouds or v2+v3 clouds. | 17:19 |
| catherineD | if that is the case, for the interop purpose as long as they pass the tests do we care whether it is v2 or v3? | 17:20 |
| markvoelker | So kind of meets Chris's ask that v2 or v3 be ok, while also making it explicit that v2 and v3 are separate things and we may not always require both | 17:20 |
| markvoelker | E.g. if down the line Cinder deprecates v2 or clients simply quit using it to the point that it's scores drop below threshhold, we can remove it | 17:20 |
| catherineD | besides I am not sure we can for sure know that whether the test are passed because of v2 or v3 ... | 17:20 |
| catherineD | then at the point the people do not support v3 will not pass the tests | 17:21 |
| catherineD | if v2 is deprecates | 17:21 |
| markvoelker | Correct. | 17:21 |
| catherineD | becaue enable v2 or v3 is a configuration related . | 17:21 |
| catherineD | we have no way to know whether the user configure v2 or v3 unless there are tests testing for that ... | 17:22 |
| markvoelker | Since the v3 stuff is advisory for 2017.01, that basically means we're not requiring v3 yet. When we get to 2017.08 we might decide the best thing to do is drop the version identifier and say "as long as you pass the tests we don't care if it's v2 or v3". | 17:22 |
| catherineD | +++ | 17:23 |
| markvoelker | When we hit 2019.01 (or something) v2 may be ready to be retired or we might have capabilities that require a specific microversion (e.g. 3.7) | 17:23 |
| markvoelker | I think what I want to do is find a way to be very clear what's required in cases like these | 17:23 |
| catherineD | we should celebrate ( :-) ) if version are changes but the same tests still pass ... that is good news | 17:23 |
| markvoelker | =) +1 | 17:24 |
| markvoelker | I wonder if we really just need to have some sort of API version identifier in the schema, frankly | 17:24 |
| markvoelker | E.g. some way we can say explicitly: "for Cinder, it's ok as of this Guideline to run v2 or v3 as long as these tests pass" | 17:24 |
| markvoelker | And in later Guidelines be able to change it to say "You will now need to be running at least 3.7 or some of these tests are going to fail" | 17:25 |
| markvoelker | We've kind of dealt with major-version API changes using capability names in the past, but that's starting to feel...overloaded. | 17:26 |
| catherineD | that is a good plan .. | 17:26 |
| markvoelker | ...which brings us back to the "combined option" we were discussing. =) | 17:26 |
| markvoelker | For now we leave this patch as-is, and then do a follow-up patch to add something to the schema | 17:27 |
| markvoelker | I may try to whip up a schema change patch this afternoon as a proof of concept for discussion | 17:28 |
| eglute | thanks markvoelker | 17:29 |
| markvoelker | Ultimately we can use the "description" field in each capability for notes like this if we need to...but feels like it's time to make version(s) more explicit. | 17:31 |
| markvoelker | Ok, speaking of meetings, I need to run if I'm going to get lunch today before my next one | 17:32 |
| markvoelker | shamail: this kinda got lost in the API transition discussion, but two things of interest on that patch: | 17:33 |
| markvoelker | shamail: first, is there a bug/patch in the works to create a test for api version discovery? If not I feel more hesitant to include it, but wouldn't rule it out since they're easy to write (we've done this before) | 17:34 |
| markvoelker | shamail: second, volumes-v2-upload was previously advisory. Any reason not to move it to required? | 17:34 |
| catherineD | I need to step out too .. .will check the log later | 17:35 |
| markvoelker | thanks catherineD | 17:35 |
| *** galstrom_zzz is now known as galstrom | 18:48 | |
| *** pcaruana has quit IRC | 18:52 | |
| *** galstrom is now known as galstrom_zzz | 19:32 | |
| *** galstrom_zzz is now known as galstrom | 19:32 | |
| *** galstrom is now known as galstrom_zzz | 19:33 | |
| *** eglute has quit IRC | 19:36 | |
| *** eglute has joined #openstack-interop | 19:36 | |
| *** galstrom_zzz is now known as galstrom | 19:39 | |
| *** galstrom is now known as galstrom_zzz | 21:18 | |
| *** masayukig has quit IRC | 22:38 | |
| *** masayukig has joined #openstack-interop | 22:38 | |
| *** openstack has joined #openstack-interop | 22:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!