14:00:09 #startmeeting glance 14:00:10 Meeting started Thu Aug 11 14:00:09 2016 UTC and is due to finish in 60 minutes. The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:14 The meeting name has been set to 'glance' 14:00:15 #topic roll call 14:00:23 o/ 14:00:28 o/ 14:00:37 o/ 14:00:47 o/ 14:01:14 o/ 14:01:18 o/ 14:01:22 o/ 14:01:47 let's get started 14:01:51 #topic agenda 14:01:58 short agenda today 14:02:01 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:02:21 let's give some time for Q&A about any outstanding questions with defcore team 14:02:35 hi eveyone 14:03:06 * hogepodge defcore representative waves 14:03:40 thanks for joining 14:05:05 Does anyone have any questions about how the process or guidelines work? 14:07:02 hey sorry, I lost power for a few mins :) 14:07:06 #chair rosmaita 14:07:07 Current chairs: nikhil rosmaita 14:07:52 hogepodge: let's give smoe time at the end of the meeting as some folks arrive late 14:07:57 (may arrive) 14:08:19 no mfedosin today 14:08:25 or kairat 14:08:39 nikhil: I may not be able to spend the entire meeting. I'm on travel right now. 14:09:02 hogepodge: thank you for being willing to take questions 14:09:25 o/ 14:09:46 hogepodge: I see, lemme shuffle the agenda then 14:09:57 #topic Glare updates 14:10:51 #info Glare updates will be given asnchronously about their move away from Glance in review https://review.openstack.org/#/c/352564/ over the next few weeks. mfedosin has agreed to update the patch as developments are seen on his end. 14:11:12 for other glare updates, please visit their weekly meeting on mondays 14:11:36 From next week onward, I will remove this updated item from glance meeting agenda. 14:11:37 Thanks. 14:12:13 #topic Q&A with hogepodge (Chris from DefCore team) 14:12:15 i don't want to stir anything up, but i have a question in case anyone feels like answering 14:12:20 hogepodge: I have the topic set now 14:12:21 about glare 14:12:26 i am too late 14:12:33 i will wait for open discussion 14:12:38 rosmaita: thanks! 14:13:26 Does anyone have any questions for hogepodge about how the process or guidelines work (DefCore) ? 14:14:08 We're crafting a new guideline to be approved by the board later this month 14:14:11 #link https://review.openstack.org/#/c/351339/ 14:14:36 We're including direct image operations for the first time since DefCore was launched last year 14:15:02 #link http://git.openstack.org/cgit/openstack/defcore/tree/next.json#n48 14:15:25 #link http://git.openstack.org/cgit/openstack/defcore/tree/next.json#n1395 14:15:35 (earlier it used to be compute proxy for images) 14:16:20 Yes, and that turned out to be problematic for a number of reasons. In general the community has signaled that compute proxies should be avoided where possible 14:17:13 We've deprecated the proxies, which makes them not required 14:17:19 #link http://git.openstack.org/cgit/openstack/defcore/tree/next.json#n1392 14:17:29 (in the next guideline) 14:18:57 One of the criteria we use in determining capabilities is that it needs to have been available for all of the covered releases, so brand new APIs and capabilities have a time lag before they can be considered required for interoperability 14:19:13 so i guess this is nice for us, since operators will have to expose glance to end-users, whereas before they didn't 14:19:57 rosmaita: yes, previously we only required direct access to keystone, nova, and (optionally) swift 14:22:00 hogepodge: I've a question about testing coverage once you have completed with the information dispersal 14:22:13 nikhil: please, go ahead 14:23:20 hogepodge: ok, may be 3 ques. so, I see in those guidelines that there are tempest tests mentioned for some capabilities. 1) Do images APIs mentioned already in that list have tempest coverage? 14:23:51 2) Who is assigned to maintain those tests in tempest or otherwise location? (any liaison or do we need to have one from glance?) 14:24:25 3) Who is assigned for adding tests once we make the APIs ready (or someone who needs to stay in touch when that tests needs to be added) ? 14:24:28 * nikhil done 14:25:18 So for 1) we have a tool that checks API coverage. I can't say for certain right now which API endpoints we're exercising, but I could put that together for you with a bit of time. 14:25:50 It parses the subunit output from Tempest 14:26:14 We only take tests from Tempest right now, in part from guidance from the TC 14:26:59 2) The tests are maintained by the QA team, in collaboration with the DefCore team, and hopefully in collaboration with, in this case, the Glance team 14:27:47 QA typically warns us if anything is going to change with a DefCore test, and we've also added our own tests to improve capability coverage, and have modified existing tests to remove unnecessary requirements 14:29:04 Where we can, we prefer to defer to team members, since they are the true subject matter experts. So, if your team were to look at the existing list and identify gaps that we should cover, I'd be very interested in working with you to modify or write new tests 14:30:01 i guess my main concern about the testing is that there is not a very clear connection between (1) defcore capability name (e.g., 'images-v2-remove'), (2) tempest tests names, and (3) what the tests actually do 14:30:03 3) With new APIs, our preference is for the team to write the tests and have them be in the Tempest tree 14:30:14 you only see (1) and (2) in the defcore json doc 14:30:28 So you need to look at the tests to see what the capability really means, but I personally find tempest very difficult to read ... lot of inheritance and hence a lot of digging to figure out what the tests actually do 14:31:03 maybe they are easier to write than read 14:31:28 rosmaita: yes, Tempest can be a bit opaque because of the client inheritance. The test code itself I think is usually pretty straight forward, usually along the lines of "create resource see if resource exists" 14:32:17 rosmaita: that's part of why we have a tool that enumerates which APIs are exercised by each test, to help us make sure that we're getting the right coverage 14:33:17 rosmaita: we went with Tempest because it's meant as an API and integration testing tool, and it's what we had. We want to keep using it, and the QA team has been responsive to our needs 14:33:18 that's good, so if an non-required feature were being used, you could detect it? 14:33:33 (that's been my main concern) 14:33:49 tests in the past did all sorts of stuff not related to the capability name 14:33:53 hogepodge: there was discussions at least some point that defcore would need it's own test set (or at least clear subset of tempest tests). Did that happen or are you guys still relying fully on the tempest suite 14:33:57 ? 14:33:59 rosmaita: sometimes, yes. In the past we've found it because a vendor has identified it in a test failure 14:34:57 hogepodge: well, it sounds like defcore committee is taking steps to address this, so that's great 14:35:05 ++ 14:35:13 Jokke_: we're still relying on Tempest. We want to avoid having to maintain our own test suite, for a bunch of reasons not limited to available resources. If we can't meet our goal of maintaining an interoperability test suite with it, we would consider other options 14:36:20 just out of curiosity, have any of the glance devs here worked with tempest (either using or contributing) 14:36:23 rosmaita: we have as a principle that tests should have the minimum number of requirements 14:36:51 another question: does DefCore have a way to detect that some vendos is NOT using the upstream code, resulting into disqualification for their interop badge? or things are API centric atm? 14:37:01 vendors are * 14:37:05 rosmaita: so booting an image requires that an image exist, which means some dependencies may creep in. We want to make sure that if they do exist, they only exist across required capabilities. 14:37:28 rosmaita: but test only the minimal functionality, and we've removed tests that require too much 14:37:51 rosmaita: I have a tiny bit of experience while working on a issue 14:38:29 nikhil: We don't have a way. It's based on trust. There's also some fuzz around the requirements. We don't require every line of upstream OpenStack, rather the sections listed in the designated sections 14:39:07 hogepodge: thanks for clarifying 14:39:10 nikhil: there's a balancing act there, but in general I've found that vendors who modify the code usually start failing the tests because of unintended side effects, so they catch themselves 14:40:03 hogepodge: ha, that's one way to let them fail.. :) 14:40:53 nikhil: it's definitely interesting, and there's usually a business decision behind it, which I try to understand and communicate back to the working group and the community 14:41:13 hogepodge: does defcore release any statistics about the compliance of the clouds the info was collected vs. the new quidelines? 14:41:39 hogepodge: looks like a grey area to me. it does stir up a few other pieces of unrelated-to-defcore conversations 14:42:06 hogepodge: what I mean is like do you have statistics of how many clouds for example does not qualify out of the ones that were used to make the new version 14:42:14 I think that's part of the mission of refstack project? 14:42:14 Jokke_: we gather data on refstack.openstack.org, but it's all a bit rough right now, and we're working on improving the data reporting tools 14:42:25 Jokke_: we can take old test results and compare them to upcoming guidelines 14:43:00 hogepodge: so it's not done currently 14:43:02 Jokke_: it's difficult to process, because lots of vendors send in a minimal data set, so we can't compare them to future releases 14:43:27 Jokke_: We do have a few proactive vendors who always try to stay on top of the proposed guidelines and report problems back to us, it's been helpful 14:45:03 sorry to ruin the fun guys, I will have to do a time check here 14:45:13 let's give another couple mins for any last question 14:45:58 I'm available for questions outside of this meeting too. You can ping me at any time on irc or email and I'll get back to you as quickly as I can 14:46:03 hogepodge: no offence intended, I've just got more and more concerned about the credibility the more I've been following this defcore discussion. thus trying to find something to provide the reasoning for these efforts 14:46:49 hogepodge: is it fair to say that it's mostly about protecting the openstack "brand"? 14:46:55 Jokke_: every test we choose has a few features. They exercise non-admin APIs, so are available to all users of a cloud, and are run hundreds of time every day in the integrated gate 14:47:30 rosmaita: I see it as we are using the OpenStack brand to protect the interoperable API 14:47:45 ok, that's a good way to put it 14:48:03 hogepodge: Thanks for answering all the questions with great detail. I will let the glance team ask more questions offline. We can schedule another Q&A if needed and if you're available/interested. 14:48:06 rosmaita: to keep vendors from modifying OpenStack in a way that winds up being harmful for end users who expect consistent behavior 14:48:12 so i basically had it backwards 14:48:16 :) 14:49:02 Thanks for participating guys. I need to give a few updates that are important. so moving onto the next topic. 14:49:06 Thanks everyone, I understand your concerns and skepticism, but we really are trying to do right for the developers, users, and vendors 14:49:06 thanks again hogepodge 14:49:15 nikhil: thank you. 14:49:24 nice 14:49:28 :) 14:49:29 #topic Nova, Horizon, etc. v1, v2 updates ( nikhil ) 14:49:41 #link https://review.openstack.org/#/c/320039/ 14:49:47 That's the horizon port to v2 14:50:06 they are trying to do it the right way so please help them with your expertise. 14:50:18 I took a quick look and pointed out the most relevant bit. 14:50:55 but it's not that the code is gunna stick, hopefully horizon team will collaborate further too. 14:51:30 Mike was working on some nova improvements that help make v1 -> v2 transition for using v2 schemas more friendly (less error prone). 14:51:49 He's not here today, but I will sync with him offline to ensure that's done/ 14:51:59 any question? 14:52:12 going 1.. 14:52:15 going 2.. 14:52:20 #topic Releases updates ( nikhil ) 14:52:33 #link https://review.openstack.org/#/c/352665 14:52:48 #link https://review.openstack.org/#/c/348507/ 14:53:00 Please get that merged asap 14:53:16 it's really important that we sync glance_store changes in glance! 14:53:33 (another one of these off-the-band syncs but critical one) 14:54:32 I want to release store next week and if we can identify anything we need to do in store before that release, it would make things easier over next 2 weeks. 14:55:12 Please also review this code asap as it's release critical to backport releases: 14:55:15 #link https://review.openstack.org/#/q/I4018af408fa45f3ac0ad6e9c8229428a9f87089f,n,z 14:55:51 to help with testing, a patch is ready (if people are not willing to budge on the exisint proposals) 14:55:53 #link https://review.openstack.org/#/c/352592/ 14:56:02 thanks in advance! 14:56:09 any question? 14:56:24 going 1.. 14:56:27 going 2.. 14:56:33 #topic open discussion 14:56:48 rosmaita: you'd a question about glare? 14:57:01 i will skip what i was going to bring up, let's use the 3.5 min to review what you linked above 14:57:49 nikhil: are any changes expected in glance with the removal of s3 driver from glance_store? 14:58:07 abashmak: https://review.openstack.org/#/c/348507/ :) 14:58:48 (btw, that's linked above) 14:58:51 my bad, missed that link 14:58:55 (above too*) 14:58:56 np 14:59:24 * nikhil wonders only if the bot would generate description from review links 14:59:44 thanks all for joining! 14:59:48 have a good day. 14:59:52 #endmeeting