14:00:09 <nikhil> #startmeeting glance
14:00:10 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:14 <openstack> The meeting name has been set to 'glance'
14:00:15 <nikhil> #topic roll call
14:00:23 <rosmaita> o/
14:00:28 <tsymanczyk> o/
14:00:37 <abashmak> o/
14:00:47 <itisha> o/
14:01:14 <abhishekk> o/
14:01:18 <hogepodge> o/
14:01:22 <aavraham> o/
14:01:47 <nikhil> let's get started
14:01:51 <nikhil> #topic agenda
14:01:58 <nikhil> short agenda today
14:02:01 <nikhil> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:02:21 <nikhil> let's give some time for Q&A about any outstanding questions with defcore team
14:02:35 <hogepodge> hi eveyone
14:03:06 * hogepodge defcore representative waves
14:03:40 <tsymanczyk> thanks for joining
14:05:05 <hogepodge> Does anyone have any questions about how the process or guidelines work?
14:07:02 <nikhil> hey sorry, I lost power for a few mins :)
14:07:06 <nikhil> #chair rosmaita
14:07:07 <openstack> Current chairs: nikhil rosmaita
14:07:52 <nikhil> hogepodge: let's give smoe time at the end of the meeting as some folks arrive late
14:07:57 <nikhil> (may arrive)
14:08:19 <nikhil> no mfedosin today
14:08:25 <nikhil> or kairat
14:08:39 <hogepodge> nikhil: I may not be able to spend the entire meeting. I'm on travel right now.
14:09:02 <rosmaita> hogepodge: thank you for being willing to take questions
14:09:25 <bunting> o/
14:09:46 <nikhil> hogepodge: I see, lemme shuffle the agenda then
14:09:57 <nikhil> #topic Glare updates
14:10:51 <nikhil> #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 <nikhil> for other glare updates, please visit their weekly meeting on mondays
14:11:36 <nikhil> From next week onward, I will remove this updated item from glance meeting agenda.
14:11:37 <nikhil> Thanks.
14:12:13 <nikhil> #topic Q&A with hogepodge (Chris from DefCore team)
14:12:15 <rosmaita> i don't want to stir anything up, but i have a question in case anyone feels like answering
14:12:20 <nikhil> hogepodge: I have the topic set now
14:12:21 <rosmaita> about glare
14:12:26 <rosmaita> i am too late
14:12:33 <rosmaita> i will wait for open discussion
14:12:38 <nikhil> rosmaita: thanks!
14:13:26 <nikhil> Does anyone have any questions for hogepodge about how the process or guidelines work (DefCore) ?
14:14:08 <hogepodge> We're crafting a new guideline to be approved by the board later this month
14:14:11 <hogepodge> #link https://review.openstack.org/#/c/351339/
14:14:36 <hogepodge> We're including direct image operations for the first time since DefCore was launched last year
14:15:02 <hogepodge> #link http://git.openstack.org/cgit/openstack/defcore/tree/next.json#n48
14:15:25 <hogepodge> #link http://git.openstack.org/cgit/openstack/defcore/tree/next.json#n1395
14:15:35 <nikhil> (earlier it used to be compute proxy for images)
14:16:20 <hogepodge> 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 <hogepodge> We've deprecated the proxies, which makes them not required
14:17:19 <hogepodge> #link http://git.openstack.org/cgit/openstack/defcore/tree/next.json#n1392
14:17:29 <hogepodge> (in the next guideline)
14:18:57 <hogepodge> 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 <rosmaita> 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 <hogepodge> rosmaita: yes, previously we only required direct access to keystone, nova, and (optionally) swift
14:22:00 <nikhil> hogepodge: I've a question about testing coverage once you have completed with the information dispersal
14:22:13 <hogepodge> nikhil: please, go ahead
14:23:20 <nikhil> 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 <nikhil> 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 <nikhil> 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 <hogepodge> 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 <hogepodge> It parses the subunit output from Tempest
14:26:14 <hogepodge> We only take tests from Tempest right now, in part from guidance from the TC
14:26:59 <hogepodge> 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 <hogepodge> 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 <hogepodge> 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 <rosmaita> 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 <hogepodge> 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 <rosmaita> you only see (1) and (2) in the defcore json doc
14:30:28 <rosmaita> 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 <rosmaita> maybe they are easier to write than read
14:31:28 <hogepodge> 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 <hogepodge> 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 <hogepodge> 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 <rosmaita> that's good, so if an non-required feature were being used, you could detect it?
14:33:33 <rosmaita> (that's been my main concern)
14:33:49 <rosmaita> tests in the past did all sorts of stuff not related to the capability name
14:33:53 <Jokke_> 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 <Jokke_> ?
14:33:59 <hogepodge> rosmaita: sometimes, yes. In the past we've found it because a vendor has identified it in a test failure
14:34:57 <rosmaita> hogepodge: well, it sounds like defcore committee is taking steps to address this, so that's great
14:35:05 <nikhil> ++
14:35:13 <hogepodge> 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 <rosmaita> just out of curiosity, have any of the glance devs here worked with tempest (either using or contributing)
14:36:23 <hogepodge> rosmaita: we have as a principle that tests should have the minimum number of requirements
14:36:51 <nikhil> 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 <nikhil> vendors are *
14:37:05 <hogepodge> 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 <hogepodge> rosmaita: but test only the minimal functionality, and we've removed tests that require too much
14:37:51 <nikhil> rosmaita: I have a tiny bit of experience while working on a issue
14:38:29 <hogepodge> 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 <nikhil> hogepodge: thanks for clarifying
14:39:10 <hogepodge> 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 <nikhil> hogepodge: ha, that's one way to let them fail.. :)
14:40:53 <hogepodge> 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 <Jokke_> hogepodge: does defcore release any statistics about the compliance of the clouds the info was collected vs. the new quidelines?
14:41:39 <nikhil> hogepodge: looks like a grey area to me. it does stir up a few other pieces of unrelated-to-defcore conversations
14:42:06 <Jokke_> 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 <nikhil> I think that's part of the mission of refstack project?
14:42:14 <hogepodge> 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 <hogepodge> Jokke_: we can take old test results and compare them to upcoming guidelines
14:43:00 <Jokke_> hogepodge: so it's not done currently
14:43:02 <hogepodge> 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 <hogepodge> 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 <nikhil> sorry to ruin the fun guys, I will have to do a time check here
14:45:13 <nikhil> let's give another couple mins for any last question
14:45:58 <hogepodge> 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 <Jokke_> 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 <rosmaita> hogepodge: is it fair to say that it's mostly about protecting the openstack "brand"?
14:46:55 <hogepodge> 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 <hogepodge> rosmaita: I see it as we are using the OpenStack brand to protect the interoperable API
14:47:45 <rosmaita> ok, that's a good way to put it
14:48:03 <nikhil> 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 <hogepodge> 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 <rosmaita> so i basically had it backwards
14:48:16 <rosmaita> :)
14:49:02 <nikhil> Thanks for participating guys. I need to give a few updates that are important. so moving onto the next topic.
14:49:06 <hogepodge> 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 <nikhil> thanks again hogepodge
14:49:15 <hogepodge> nikhil: thank you.
14:49:24 <nikhil> nice
14:49:28 <nikhil> :)
14:49:29 <nikhil> #topic Nova, Horizon, etc. v1, v2 updates ( nikhil )
14:49:41 <nikhil> #link https://review.openstack.org/#/c/320039/
14:49:47 <nikhil> That's the horizon port to v2
14:50:06 <nikhil> they are trying to do it the right way so please help them with your expertise.
14:50:18 <nikhil> I took a quick look and pointed out the most relevant bit.
14:50:55 <nikhil> but it's not that the code is gunna stick, hopefully horizon team will collaborate further too.
14:51:30 <nikhil> 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 <nikhil> He's not here today, but I will sync with him offline to ensure that's done/
14:51:59 <nikhil> any question?
14:52:12 <nikhil> going 1..
14:52:15 <nikhil> going 2..
14:52:20 <nikhil> #topic Releases updates ( nikhil )
14:52:33 <nikhil> #link https://review.openstack.org/#/c/352665
14:52:48 <nikhil> #link https://review.openstack.org/#/c/348507/
14:53:00 <nikhil> Please get that merged asap
14:53:16 <nikhil> it's really important that we sync glance_store changes in glance!
14:53:33 <nikhil> (another one of these off-the-band syncs but critical one)
14:54:32 <nikhil> 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 <nikhil> Please also review this code asap as it's release critical to backport releases:
14:55:15 <nikhil> #link https://review.openstack.org/#/q/I4018af408fa45f3ac0ad6e9c8229428a9f87089f,n,z
14:55:51 <nikhil> to help with testing, a patch is ready (if people are not willing to budge on the exisint proposals)
14:55:53 <nikhil> #link https://review.openstack.org/#/c/352592/
14:56:02 <nikhil> thanks in advance!
14:56:09 <nikhil> any question?
14:56:24 <nikhil> going 1..
14:56:27 <nikhil> going 2..
14:56:33 <nikhil> #topic open discussion
14:56:48 <nikhil> rosmaita: you'd a question about glare?
14:57:01 <rosmaita> 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 <abashmak> nikhil: are any changes expected in glance with the removal of s3 driver from glance_store?
14:58:07 <nikhil> abashmak: https://review.openstack.org/#/c/348507/ :)
14:58:48 <nikhil> (btw, that's linked above)
14:58:51 <abashmak> my bad, missed that link
14:58:55 <nikhil> (above too*)
14:58:56 <nikhil> np
14:59:24 * nikhil wonders only if the bot would generate description from review links
14:59:44 <nikhil> thanks all for joining!
14:59:48 <nikhil> have a good day.
14:59:52 <nikhil> #endmeeting