2016-04-13 16:00:01 eglute #startmeeting defcore 2016-04-13 16:00:23 <-- vtech (~vtech@160.85.127.192) has quit (Quit: My Mac has gone to sleep. ZZZzzz…) 2016-04-13 16:00:29 markvoelker hmm...bots offline again? 2016-04-13 16:00:29 eglute no bot? 2016-04-13 16:00:43 eglute did i misspell something? 2016-04-13 16:00:44 --> gema (~Gema@host81-155-132-42.range81-155.btcentralplus.com) has joined #openstack-meeting-3 2016-04-13 16:00:48 docaedo looks right to me 2016-04-13 16:00:56 --> catherineD (~kvirc@32.97.110.54) has joined #openstack-meeting-3 2016-04-13 16:01:11 eglute yeah, other meeting rooms complain of no bots 2016-04-13 16:01:12 docaedo maybe meetingbot is on a break and will jump back in momentarily ;) 2016-04-13 16:01:23 eglute Anyways, here is the agenda: https://etherpad.openstack.org/p/DefCoreRing.19 2016-04-13 16:01:32 gema o/ 2016-04-13 16:01:36 catherineD o/ 2016-04-13 16:01:38 markvoelker Let's sally forth anyway, I'll copy/paste a transcript into the pad when we're done. 2016-04-13 16:01:39 luzC o/ 2016-04-13 16:01:39 docaedo I can share my log with infra after the meeting 2016-04-13 16:01:44 eglute thanks mrunge 2016-04-13 16:01:48 eglute err, thanks markvoelker 2016-04-13 16:01:50 docaedo o/ 2016-04-13 16:02:00 <-- spzala (spzala@nat/ibm/x-qvkbsrygzilyrznm) has quit (Ping timeout: 244 seconds) 2016-04-13 16:02:01 --> vtech (~vtech@160.85.127.192) has joined #openstack-meeting-3 2016-04-13 16:02:04 eglute #topic next week's meeting 2016-04-13 16:02:07 --> dwalleck (~dwalleck@50.56.229.24) has joined #openstack-meeting-3 2016-04-13 16:02:10 <-- vtech (~vtech@160.85.127.192) has quit (Client Quit) 2016-04-13 16:02:12 hogepodge o/ 2016-04-13 16:02:15 dwalleck o/ 2016-04-13 16:02:31 eglute just a quick check- is everyone planning on attending next week's IRC meeting? 2016-04-13 16:02:41 * markvoelker is planning to attend 2016-04-13 16:02:45 * hogepodge is 2016-04-13 16:02:46 dwalleck yup 2016-04-13 16:02:46 * docaedo is planning to attend 2016-04-13 16:02:47 gema yep 2016-04-13 16:02:54 <-- numans (numans@nat/redhat/x-ohbggcoenkeebebx) has quit (Ping timeout: 260 seconds) 2016-04-13 16:02:54 catherineD yea 2016-04-13 16:02:56 eglute cool, then we will have it! 2016-04-13 16:03:15 eglute Next topic then! since we didnt get to it last week 2016-04-13 16:03:20 eglute #Keystone scoring 2016-04-13 16:03:32 <-- itxaka (~itxaka@213.219.149.76.adsl.dyn.edpnet.net) has quit (Quit: Leaving) 2016-04-13 16:03:47 gema uploaded the new version of the patch a while ago and haven't had any further comments 2016-04-13 16:03:53 gema not sure if that is good or bad 2016-04-13 16:03:57 gema eglute: thanks for the thumbs up :D 2016-04-13 16:04:02 eglute #link https://review.openstack.org/#/c/297847/ 2016-04-13 16:04:14 markvoelker gema: whoops, somehow I missed the second patchset. Will review today. 2016-04-13 16:04:25 gema markvoelker: thanks! 2016-04-13 16:04:27 eglute looks like we have one new capability for keystone 2016-04-13 16:04:39 eglute identity-v3-api-discovery 2016-04-13 16:04:47 gema yeah, it was advisory last cycle 2016-04-13 16:04:59 eglute thank you Gema! 2016-04-13 16:05:08 gema yw 2016-04-13 16:05:31 eglute anyone else have a chance to review? 2016-04-13 16:05:32 hogepodge It looks good to me 2016-04-13 16:05:38 --> e0ne (~e0ne@178.151.129.193) has joined #openstack-meeting-3 2016-04-13 16:05:40 eglute thank you hogepodge 2016-04-13 16:05:57 eglute will give it another day and if all looks good, we will merge it 2016-04-13 16:06:06 gema :D 2016-04-13 16:06:26 eglute ready for next topic? 2016-04-13 16:06:31 catherineD so other than the identity-v3-api-discovery: identity-v3-catalog: also score high 2016-04-13 16:06:41 gema catherineD: yes, but no tests 2016-04-13 16:06:51 gema catherineD: I was planning to address that on the spec 2016-04-13 16:07:15 catherineD but have not tests ... do we just put identity-v3-catalog: in advisory with empty test based on the practice in https://review.openstack.org/#/c/305269/ 2016-04-13 16:07:23 hogepodge can we add as work item to talk with keystone and qa about adding a test or two for catalog? 2016-04-13 16:07:38 gema yeah, I can do that 2016-04-13 16:07:57 eglute hogepodge that sounds good... where can we keep work items? 2016-04-13 16:08:08 hogepodge we can add catalog as an advisory capability, then fill the tests in for next as they arrive (or drop the capability if they never do) 2016-04-13 16:08:17 markvoelker Remind me: is it a case of no tests exist, or tests do exist but are unsuitable (e.g. require admin or something) 2016-04-13 16:08:18 catherineD it will take time to add test ,,, meanwhile we accept empty test list? 2016-04-13 16:08:18 markvoelker ? 2016-04-13 16:08:32 <-- rhochmuth (Adium@nat/hp/x-laxedgheiavrowqy) has left #openstack-meeting-3 2016-04-13 16:08:41 gema markvoelker: I need to reread the review, it's been too long 2016-04-13 16:08:43 --> amotoki (~amotoki@FL1-119-242-22-153.tky.mesh.ad.jp) has joined #openstack-meeting-3 2016-04-13 16:08:49 eglute i rather we do not have empty capabilities without tests 2016-04-13 16:08:51 gema markvoelker: you said for one of them there was an admin test 2016-04-13 16:08:54 hogepodge eglute: that's a good question, we have quite a few reviews that could use cooperation with upstream. Maybe an etherpad? Or Launchpad? Don't know. 2016-04-13 16:09:04 gema hogepodge: blueprint? 2016-04-13 16:09:27 --> sdake_ (~sdake@128.107.241.171) has joined #openstack-meeting-3 2016-04-13 16:09:31 docaedo I would think blueprint on launchpad would be best 2016-04-13 16:09:52 --> openstack (~openstack@openstack/openstack) has joined #openstack-meeting-3 2016-04-13 16:09:52 -- Mode #openstack-meeting-3 [+o openstack] by ChanServ 2016-04-13 16:09:53 markvoelker So, if there are tests that exist and we think there's a reasonable chance they could be made suitable, I'd be more inclined to include those and let it be advisory. 2016-04-13 16:09:56 gema we'll need a project in launchpad 2016-04-13 16:10:01 gema and then we can create blueprints 2016-04-13 16:10:12 markvoelker If there are no tests at all, we can't even really articulate what the capability is to people, so it feels like that shouldn't go in... 2016-04-13 16:10:23 eglute markvoelker i agree 2016-04-13 16:10:40 eglute gema hogepodge how do we get a project in launchpad 2016-04-13 16:10:41 gema markvoelker: the api is there and I can call it without admin 2016-04-13 16:10:47 gema eglute: we just create it 2016-04-13 16:11:09 eglute #action gema hogepodge to create DefCore project in launchpad 2016-04-13 16:11:10 gema eglute: I will put instructions together for hogepodge to create, once it is created I don't think you can change teh person that owns it 2016-04-13 16:11:13 catherineD markvoelker: I think that is the case for identity-v3-catalog: .. there seems to be no test 2016-04-13 16:11:18 <-- sdake (~sdake@ip98-165-69-137.ph.ph.cox.net) has quit (Ping timeout: 244 seconds) 2016-04-13 16:11:29 markvoelker gema: But if I'm reading that Guideline doc, how do I know that "identity-v3-catalog" means "this particular API"? 2016-04-13 16:11:52 gema markvoelker: you don't atm 2016-04-13 16:12:00 gema unless you look at my doc 2016-04-13 16:12:04 eglute i agree with markvoelker. in this case we will leave it out of the guideline 2016-04-13 16:12:05 gema (the spreadsheet) 2016-04-13 16:12:08 markvoelker gema: if there are tests there then I have some idea of what may become required in the future. If not... 2016-04-13 16:13:11 eglute gema i think we can use your spreadsheet as a started for blueprint in this case 2016-04-13 16:13:15 docaedo re: launchpad, why not use refstack? since that already exists and most of the work relating to tests funnels through that, does it make sense to have a new launchpad page for some subset of the work? 2016-04-13 16:13:23 gema markvoelker: catalog in particular is special, this is payload that is returned as part of one capability that is already there 2016-04-13 16:14:03 eglute docaedo i rather not mix the two projects. the tests are not really part of refstack 2016-04-13 16:14:10 gema markvoelker, eglute ok, we are not adding new capabilities without tests this time around and I will get tests for the things that scored high but don't have them yet 2016-04-13 16:14:27 eglute thank you gema! 2016-04-13 16:14:36 markvoelker gema: agreed, there's that atomicity thing again. =) Thanks for working on this. 2016-04-13 16:14:44 gema markvoelker: welcome! 2016-04-13 16:14:49 eglute next topic? 2016-04-13 16:14:58 hogepodge catalog is one of those things that is a side effect that will cause lots of tests to fail if it doesn't work, but it's good to test these things directly 2016-04-13 16:15:16 hogepodge I'm happy to work with upstream to get something there so we can add advisory later. 2016-04-13 16:15:19 --> sdake (~sdake@ip98-165-69-137.ph.ph.cox.net) has joined #openstack-meeting-3 2016-04-13 16:15:23 eglute thanks hogepodge 2016-04-13 16:15:28 eglute that would be great 2016-04-13 16:15:28 gema thanks 2016-04-13 16:15:42 eglute #topic Flag tests removed from tempest 2016-04-13 16:15:49 catherineD if indeed no test exists today .. this is a good case to create a test per DefCore test spec 2016-04-13 16:15:51 eglute #link https://review.openstack.org/#/c/289071/ 2016-04-13 16:16:02 eglute catherineD +1 2016-04-13 16:16:05 hogepodge Seems pretty easy. But it makes some capabilities empty 2016-04-13 16:16:23 catherineD that just mean that we need the DefCore spec quick :-) 2016-04-13 16:16:37 markvoelker Have we actually looked to see if there are any other tests we could use for those capabilities? 2016-04-13 16:16:53 gema markvoelker: I did and couldn't find any 2016-04-13 16:17:00 dwalleck markvoelker: or we could add ones if they don't exist 2016-04-13 16:17:00 markvoelker gema: =/ 2016-04-13 16:17:03 gema markvoelker: but this is the first time I do it, so could be wrong 2016-04-13 16:17:07 <-- sdake_ (~sdake@128.107.241.171) has quit (Ping timeout: 260 seconds) 2016-04-13 16:17:19 gema dwalleck: that's a good idea :D 2016-04-13 16:17:22 hogepodge they're removing the tests because auth is used all over the place so why test auth? It's kind of weird to me, actually 2016-04-13 16:17:31 catherineD dwalleck: do we want to have the spec first ? so this will be an example to add a DefCore test 2016-04-13 16:17:45 catherineD hogepodge: +1 2016-04-13 16:17:47 --> jmckind_ (~jmckind@72.32.180.182) has joined #openstack-meeting-3 2016-04-13 16:17:50 gema hogepodge: auth should be tested explicitely 2016-04-13 16:17:51 eglute i am in favor of starting with the spec 2016-04-13 16:17:57 --> janki_chhatbar (~chatzilla@117.212.214.86) has joined #openstack-meeting-3 2016-04-13 16:18:08 gema eglute: the spec is ongoing, it's the last topic on the agenda 2016-04-13 16:18:14 dwalleck catherineD: We do have existing tests 2016-04-13 16:18:21 catherineD gema: we do not enforce test sequences during test runs ... 2016-04-13 16:18:34 gema catherineD: good 2016-04-13 16:18:55 eglute so for https://review.openstack.org/#/c/289071/ 2016-04-13 16:19:05 markvoelker Working on the spec is definitely something we want to do. The bigger question is what to do with the empty capabilities in the interim 2016-04-13 16:19:08 dwalleck eglute: But if the spec is just the guidelines for what makes a good test (not what the capability should do), then it would be a nice to have 2016-04-13 16:19:10 catherineD dwalleck: if test exists then we are good 2016-04-13 16:19:24 catherineD markvoelker: +1 2016-04-13 16:19:30 eglute if there are no tests, i am in favor of removing empty capabilities 2016-04-13 16:19:30 gema markvoelker: I'd leave them in the working file for now 2016-04-13 16:19:34 <-- lpetrut (~Thunderbi@89.46.161.178) has quit (Ping timeout: 244 seconds) 2016-04-13 16:19:35 markvoelker If it's realistically going to be test-less for some time (while we build the spec and create new tests) I think I'd be in favor of dropping them. 2016-04-13 16:19:38 gema and act on them when tests become available 2016-04-13 16:19:46 eglute markvoelker +1 2016-04-13 16:19:49 markvoelker gema: ++ 2016-04-13 16:19:51 hogepodge we have had test-less capabilities before 2016-04-13 16:20:20 catherineD hogepodge: those it is not merged we do have idea like this https://review.openstack.org/#/c/233814/ 2016-04-13 16:20:23 hogepodge it's still a statement of intent 2016-04-13 16:20:44 markvoelker hogepodge: I'm thinking my personal rule=of-thumb might be if we're expecting them to be testless for one Guideline, we drop them. 2016-04-13 16:21:01 eglute i agree with markvoelker 2016-04-13 16:21:07 dwalleck But if a test defines a capability and we have no tests, then how do we define the capability? 2016-04-13 16:21:16 hogepodge markvoelker: naturally, but timing matters. 2016-04-13 16:21:26 markvoelker hogepodge: agreed 2016-04-13 16:21:26 dwalleck It hurts the point that a test defines a capability 2016-04-13 16:21:27 <-- jmckind (~jmckind@cpe-24-243-1-110.satx.res.rr.com) has quit (Ping timeout: 276 seconds) 2016-04-13 16:21:27 catherineD markvoelker: how do we deal with if all tests in a capability are flagged ... the result is the same as no test 2016-04-13 16:21:36 <-- atuvenie (~atuvenie@79.114.24.100) has quit (Quit: Leaving) 2016-04-13 16:21:38 hogepodge markvoelker: they should stay in the guideline if tests did exist, they should get a full cycle rather than being yanked at the end of one 2016-04-13 16:21:45 hogepodge markvoelker: we should have time to fix the underlying problem 2016-04-13 16:22:02 markvoelker catherineD: depends on the reason for the flags. If they're flagged because of a bug in the feature or the test that is being worked on, I don't really have a problem with taht. 2016-04-13 16:22:21 markvoelker catherineD: if they're flagged because tests are going away and there are no realistic substitutes, that's a problem 2016-04-13 16:22:36 eglute i agree 2016-04-13 16:23:18 hogepodge at a finer point, some of the tests were already flagged, and the flagging company never worked on fixing the upstream problems 2016-04-13 16:23:24 hogepodge leading to empty capabilities 2016-04-13 16:23:31 markvoelker hogepodge: I think I could be amenable to that, assuming they were previously required. I'd be wary of introducing new testless capabilities though. 2016-04-13 16:23:59 --> hoangcx (~HoangCX@123.16.156.146) has joined #openstack-meeting-3 2016-04-13 16:24:04 eglute hopefully having blueprints to work with other teams will help fix this issue. 2016-04-13 16:24:27 eglute also, we are actually working on defcore specs, which hopefully will be followed by tests 2016-04-13 16:24:45 catherineD This capability objectstore-object-access has no test in 2016.01 2016-04-13 16:24:45 * markvoelker glances at the clock 2016-04-13 16:24:51 <-- vijendar (~Vijendar@2602:306:ccff:66d0:6123:c5f5:f2f:8df0) has quit (Quit: Leaving.) 2016-04-13 16:24:54 gema yeah, let's moove on xD 2016-04-13 16:25:02 <-- slogan (424b0a42@gateway/web/freenode/ip.66.75.10.66) has quit (Ping timeout: 250 seconds) 2016-04-13 16:25:06 <-- dwalleck (~dwalleck@50.56.229.24) has quit (Read error: Connection reset by peer) 2016-04-13 16:25:19 markvoelker How about if I take a stab at drafting up a HACKING entry about handling testless capabilities as a strawman and we take the discussion to gerrit? 2016-04-13 16:25:32 eglute thanks markvoelker that sounds good 2016-04-13 16:25:33 gema markvoelker: +1 2016-04-13 16:25:43 catherineD markvoelker: +1 I think this is an important topic 2016-04-13 16:25:53 markvoelker #action markvoelker draft strawman HACKING entry about testless capability handling 2016-04-13 16:26:15 eglute #topic Flag multi-tenant tests 2016-04-13 16:26:22 eglute #link https://review.openstack.org/#/c/253138/3 16:26:38 #startmeeting defcore 16:26:39 Meeting started Wed Apr 13 16:26:38 2016 UTC and is due to finish in 60 minutes. The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:26:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:26:43 The meeting name has been set to 'defcore' 16:26:57 well, at least some official logs :) 16:27:08 #topic Flag multi-tenant tests 16:27:15 #link https://review.openstack.org/#/c/253138/3 16:28:09 i am ok with flagging multi-tenant tests 16:28:39 especially since the new patch 16:28:50 hogepodge: needs a D404 proposal though (see comment from March 31) 16:29:07 it was part of different PR right? 16:29:23 yes 16:29:59 no rush on this one (as opposed to the previous), I can rework it. 16:30:37 ok, in that case will give more time for others to review it? 16:30:58 and for the D404 to be removed =) 16:31:33 in that case, next topic? 16:31:37 ++ 16:31:44 #topic 16:31:44 Preference for using direct API calls for image 16:31:45 hogepodge: I put a -1 on https://review.openstack.org/#/c/289071/ so that we can discuss testless capbility 16:31:49 #topic Preference for using direct API calls for image 16:32:07 #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/091466.html 16:32:08 hogepodge: I will remove it now that we will have some action 16:32:36 still needs a -1 for 404 :-D New change set will be forthcoming 16:33:11 thanks hogepodge 16:33:12 For this topic, longer term thinking 16:33:29 It sounds like the TC and community want to stop using nova proxies. 16:33:33 Yup. Good to see this being discussed. 16:33:53 I will be interested to know what action comes out of it. =) 16:34:03 +1 16:34:09 So, we need to think about changing up compute capabilities to match that thinking. Which we're already doing. 16:34:35 hogepodge: well, the question is whose thinking actually prevails I think. 16:35:09 markvoelker: how much contention is there over the issue of proxies? 16:36:15 hogepodge: I'm not sure. Nova has said they're not going to remove the API. 16:36:25 http://lists.openstack.org/pipermail/openstack-dev/2016-April/091479.html 16:36:43 markvoelker: nova won't remove it because microversions, afaik, but they want to discourage it heavily 16:36:45 If external tools, SDK's, and users are still using it and it isn't going away... 16:37:05 sounds like it will be a while at least 16:37:25 it causes headaches (all the flags because of glance v1 image proxy, for example) 16:37:25 eglute: I think so too 16:37:27 Right, that's what kind of what I'm getting at: if they don't want people using it, how is that message going to get out and what practical effect will it have on getting people (and SDK's, and tools, etc) to move to the Glance API's? 16:39:14 so, is this one of those topics that we can think about but do nothing about? 16:39:51 we can communicate our current state to the community to help guide discussions and decisions 16:40:13 Sure. And we can also make sure we're scoring the glance image capabilities appropriately too. 16:40:21 right now we require the proxies in some way, but should be not be requiring them in favor of the other apis? 16:40:51 hogepodge: I think so 16:41:10 at least remove/flag those from the must-pass tests 16:41:15 hogepodge: if the nova API's meet all the criteria, I have basically zero problem with them being in the Guideline. I also have zero problem with the Glance API's being in the Guideline if they meet all the criteria. 16:42:07 Basically there's nothing forcing us to pick one or the other if they both meet criteria. I do want to be mindful of the outcome of the conversation though, as it may indicate that scoring changes 16:42:12 markvoelker: then people will have not reason to move to Glance API ? 16:42:45 catherineD: they have a real reason right now. v2 is not supported by nova 16:42:54 E.g. if nova takes definitive steps to remove support for the nova image API or document it as "do not use this" then I wouldn't want to score it 1 for "future direction" for instance 16:43:07 markvoelker +1. we need to remember that defcore is trailing, not leading when it comes to new features. Yes, we look at the technical direction, and we have in the past. But it also sounds like glance v2 still has a lot of work that needs to happen 16:43:55 i suggest for the sake of time we table this discussion for a later time? 16:44:09 eglute: +1 to closing discussion and moving on 16:44:21 #topic Certifying Mitaka clouds 16:44:28 Basically I want Nova and Glance to convince the ecosystem what the best way of doing things is (or reduce the number of ways to do it, gracefully) rather than us dictating that. 16:44:31 eglute: +1 16:44:53 markvoelker i agree with you there! 16:44:57 which guideline should be used to certify Mitaka clouds? 16:45:24 we need a policy for new releases 16:45:37 i was thinking about this, and it seems like we have some pacing issues when it comes to guidelines 16:45:56 i would say new releases can be certified under the current guideline 16:46:01 how does that sound? 16:46:16 maybe we need to change supported released to say "x or newer", where x is release name 16:46:29 hogepodge +1 16:46:31 eglute: +1 16:46:36 eglute +1 16:46:42 hogepodge: for products with existing license agreements in place, are tehy currently covered with their existing agreements? 16:46:50 I can't recall the legalese in the contract 16:46:53 this line http://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json#n9 16:47:12 markvoelker: let me look at the contract 16:47:46 hogepodge right, i think we need to change it. 16:47:48 hogepodge: ok. Still wouldn't help new products being introduced for the first time, but curious what the language says now 16:48:12 if we make a change to the guideline, we need to ask for the board's approval during the next meeting 16:48:27 should not be a problem, just part of the process 16:48:39 eglute: if that is the case , how do user interpret line 9 in https://github.com/openstack/defcore/blob/master/2016.01.json means --> "releases": ["juno", "kilo", "liberty"], 16:48:59 if we can use 2016.01 to certify Mitaka clouds 16:49:06 I think it's a reasonable thing to propose. Out of curiosity, do we actually have someone trying to certify a Mitaka product already that sparked this? 16:49:12 catherineD: good question, I was about to ask the same thing 16:49:19 markvoelker: yes 16:49:27 we could add "mitaka", or say, "newer release" and point to openstack releases page 16:49:35 eglute: that works 16:49:36 markvoelker: We are - PowerVC 16:49:42 good to know =) 16:49:47 #link http://releases.openstack.org/ 16:50:02 markvoelker: yes, also I think we need to encourage people to use the new release as soon as possible :) so looks good when we can certify clouds on the newest release 16:50:06 So, changing the Guideline doc still requires Board approval. However it's ultimately up to the Foundation to grant license agreements. 16:50:46 That means that irrespective of what the Guideline doc says today they could technically still grant an exception and grant a license. 16:50:57 (until we get the Board to vote on changing the doc) 16:51:00 right, the board meeting is on the 4/24, so if have a patch that everyone agrees on, we can ask for boards approval then 16:51:10 Don't know if that's a helpful escape valve for you. =) 16:51:22 eglute: +1 16:51:47 +1 on exceptions, especially if we agree now that this will be the direction: newer releases can use current guideline 16:52:07 Who's got the AI to propose the change? 16:52:10 eglute: Need to document somewhere 16:52:19 a foundation all writs act (he kids) 16:52:36 #action hogepodge to propose a change to current guideline include newer releases 16:53:21 markvoelker: We actually have a test left to finish before we're ready to certify so waiting for board approval won't be an issue depending on their turnaround. 16:53:23 catherineD agree, was thinking after the PR is in place of sending an email to let people know 16:53:47 eglute: thanks 16:53:50 cjvolzka if approved, it would be immediate, on 4/24 16:54:07 That would be fine then 16:54:19 foundation won't hold up license agreement for mitaka, unless board or working group objects 16:54:35 Ok, cool. While that patch is getting written, I'd like to think over some of the corner cases...e.g. what happens if something gets deprecated or broken in between when a Guideline is written and when the next release comes out 16:54:59 (imagine we'd handle that with flags, but there are probably some other cases to think through) 16:55:25 Almost out of time...move on? 16:55:34 well, i think flags would cover it. bigger concern is whether we allow 2 last guidelines to be used or not 16:55:59 yes, lets move on and keep thinking about this 16:56:04 eglute: I thought it was just the current last one guideline? 16:56:37 cjvolzka currently you can certify against 2 last guidelines, but each guideline specifies releases 16:57:05 ahh ok 16:57:21 we will run out of time for other topics, but i will be in defcore IRC after 16:57:27 #topic Austin Summit 16:57:52 please start adding topics for a working session: #link https://etherpad.openstack.org/p/DefCoreRing.AustinSummit2016 16:58:19 and for refstack session: #link https://etherpad.openstack.org/p/refstack-newton-summit 16:58:38 cool 16:59:06 eglute: Dies it make sense to alert DefCore/RefStack sessions via defcore mailing list? 16:59:22 I am sure people can search too 16:59:39 catherineD yes, i will send out calendar invites to those :) 16:59:47 eglute: thanks 17:00:10 right now seems like DefCore abd RefStack sessions are not overlapping 17:00:11 we are almost out of time. stay for scoring cinder/swift in defcore IRC? 17:00:35 and Heat scoring 17:00:45 I can stick around for a couple of minutes, but have to run shortly 17:00:45 I have a call, but can try to multi-task 17:00:53 ok, i will be around 17:00:58 thanks everyone! 17:01:00 #endmeeting