16:00:25 #startmeeting interopwg 16:00:26 Meeting started Wed Oct 4 16:00:25 2017 UTC and is due to finish in 60 minutes. The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:29 The meeting name has been set to 'interopwg' 16:00:44 Hello Everyone! 16:00:53 o/ 16:00:54 hi 16:00:54 #chair markvoelker hogepodge 16:00:54 Current chairs: eglute hogepodge markvoelker 16:00:59 #topic agenda 16:01:02 #link https://etherpad.openstack.org/p/InteropVertigo.17 16:01:08 please update agenda as needed! 16:01:44 Hope everyone is doing well today 16:01:58 markvoelker said he might not be able to join us today 16:02:18 anyone else here for the interop meeting? 16:02:36 I'm here, but have a conflicting meeting so won't be fully present 16:02:49 thanks hogepodge 16:03:05 I have some thoughts about microversions though, that I'll need to work through 16:03:36 hogepodge will you time in todays meeting to share your thoughts? 16:03:52 we can start with that if it would help or do it at a specific time 16:04:27 #topic OpenStack Summit Sydney 16:04:38 If there are any additional sessions, please add them 16:05:04 I still need to have myself removed from the session listed, since I won't be attending this summit. 16:05:21 #action eglute to get herself removed from the summit session 16:06:02 #topic Vertical Program Update 16:06:18 o/ 16:06:30 thank you georgk for creating that google spreadsheet 16:06:37 #link https://docs.google.com/spreadsheets/d/1mvjo82eFsXwG-IOMfVVnGPNbNHRuOQPgxH1EtIpRuUg/edit#gid=0 16:07:04 well, it is an attempt. it feels like more details would be needed 16:07:10 everyone, if you are familiar with OPNFV, please review and provide feedback to georgk 16:07:33 o/ 16:08:17 well my time freed up so I can talk now :-D 16:08:20 georgk that spreadsheet looks like it already took a lot of work 16:08:48 great hogepodge! are you free for the rest of the hour? 16:09:37 georgk one quick note- Ceph is not part of openstack, thought they are used together often! 16:10:02 eglute: true, noted 16:10:22 some of the other projects i am not sure, since there are so many under openstack right now 16:10:55 i need to go through it once more 16:10:56 georgk markvoelker any other updates on the vertical programs? 16:11:36 one take away is anyway that functionatlity worked on by OPNFV is likely not present in commercial products now 16:12:07 I´d like to get the scoring started, but I might need a bit of advise 16:12:19 maybe I´ll ping you on IRC in the next days 16:12:26 can you elaborate on that georgk 16:12:57 eglute: on the scoring? 16:13:14 no, on the "OPNFV is likely not present in commercial products now" 16:13:37 do you expect that OPNFV will be using in commercial products? or? 16:14:54 ah, ok, no. What I meant is the following: most work in OPNFV goes into testing and building tools for integration 16:14:59 * markvoelker sneaks into the back after getting free of another meeting 16:15:43 of course there are also feature projects working more upstream, but my feeling is that the functionality/features added by those projects is not likely available in commercial products 16:16:07 hence, not yet widely deployed enough for inclusion in the vertical 16:16:25 georgk that makes sense, thank you 16:17:05 georgk markvoelker anything else on verticals? 16:17:13 also many of the OpenStack projects used in some parts of various NFV projects aren't part of many commercial offerings (how many distros carry, for example, BGP VPN or Blazar?) 16:17:54 Not much to report for me this week...I'm behind on everything since I'm covering for folks out on holiday this week unfortunately 16:18:51 (it's a national holiday week in China) 16:19:16 huh. interesting 16:19:28 * eglute wishes for a week of holidays 16:20:04 markvoelker hogepodge any ideas of commercial openstack deployments that use NFV/OPNFV? 16:23:09 i take that as a no :) 16:23:12 o/ 16:23:15 There are plenty of production deployments. Many, though, aren't built on "traditional OpenStack product offerings" like those we see in the marketplace. Rather, the deployment (or rather the things runing on top of it) are the thing being commercialized. 16:23:17 eglute: none right now, but that doesn't mean I wouldn't have more when I have a chance to think about them 16:23:42 thanks markvoelker and hogepodge 16:23:57 hogepodge can you talk on microversions now? 16:24:03 #topic microversions 16:24:04 So basically just be careful to think about that when considering capabilities and offerings...you're probably looking at a different audience here than for Powered is all. =) 16:24:36 thanks markvoelker! didnt mean to cut you off with topic change 16:24:46 no worries 16:25:02 markvoelker anything else on nfv? 16:25:29 eglute: yes 16:25:46 nope, I'm done 16:25:47 I'm trying to work out technically how to express microversions. 16:26:01 thanks markvoelker 16:26:36 Should versioning be tied to the component, the capability, or the test? I'm inclined to express minimum and maximum versions as part of the component 16:27:03 hogepodge how does testing work now with microversions? 16:27:04 because it should apply globally, but have the option to have additional information in the capability 16:27:22 eglute: for each project you can configure tempest to have a min and max version 16:27:52 hogepodge: Could we take a quick step back and think about why we need to? That might help frame the discussion. E.g. we can add a capability and a test today that happen to need a particular microversion without changing anything in the schema (it just might not be obvious to people that they need a particular microversion), right? 16:28:14 So is our intent here to be more explicit for people's edification, or...? 16:28:50 markvoelker: the worry is that we could be testing head which uses a microversion not available in older releases 16:29:46 Wouldn't that be sorted out during scoring though? E.g. we always have to check whether a given feature we're adding applies to all the covered releases anyway... 16:30:21 And we know (or can determine) when various microversions were introduced... 16:30:59 tempest might need to be configured to limit a version, though 16:31:15 folks with more experience in running and testing microversions might be able to say more 16:31:56 Ok, so the major concern is helping people configure tempest to test something appropriately? 16:32:01 could we require only a minimum micro version? 16:33:22 markvoelker: yes, and setting clear expectations 16:33:42 So, part of the problem is that openstack will always negotiate to the highest version availalbe, but that might not be a version that is still available in the approved versions 16:33:42 to vendors, to users 16:34:13 hogepodge: Ok, that's helpful. I've been wondering if the schema is even the right place to note this kind of thing. 16:34:20 So, fo testing, requiring the minumum and having tests that exercise the current max is needed 16:34:35 markvoelker: it's the source of all truth for interop 16:34:46 Rockyg: be careful when you stay "openstack will always negotiate". =) Are you talking about the client or the server? Not all clients actually do that. 16:35:27 Ooh! I didn't know that! 16:35:43 hogepodge: Right, but not the source of truth for how to configure tempest. Does kinda make logical sense to denote this in the guidelines thoug. 16:35:59 microversions are on the critical path for current scoring though, as I understand it 16:36:52 So, we need to have a way to *identify* microversions valid in the schema, but not necessarily the tempest configs. 16:37:33 markvoelker: I was looking at a way to express it that was optional, because not every project needs them. I guess one of the problems is we don't want to express a range that gets out of date either 16:37:51 hogepodge how about expressing only a minimum? 16:38:28 Yeah, we're definitely considering some capabilities in Nova and Cinder that require a particular microversion of the respective API's. But again, we could just list the capability and test per the norm and assume that since the API code is designated, if you're running one of the covered releases your cloud supports it. 16:38:36 eglute: but what if a capability changes with a version? I don't know how versioning policy works. 16:38:44 The tempest config then remains the possible issue though 16:39:27 hogepodge ack, good point. 16:39:48 versioning policy is that any time you have a backward incompatible change, you need a new microversion 16:39:54 markvoelker: so we could introduce metadata on the capability that indicates which microversion introduced it? 16:40:09 but you also need the code to allow the old stuff to work. 16:40:32 hogepodge, yes. 16:40:47 hogepodge: that's kinda what I'm thinking. An optional field that lists the microversion needed as a heads-up. 16:41:27 ok, that gives me some direction to work with 16:42:05 Thanks. mguiney and I were thinking about it the other day, but this is good guidance 16:42:09 +1 16:42:32 Rockyg: actually backward-breaking changes are what drive a bump in the major version number, not the minor one. 16:42:48 #link https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html Microversion Specification (if folks need a reference) 16:43:04 thanks markvoelker 16:44:58 hogepodge do you have enough to go on? 16:45:02 I'm thinking that that might be not be being enforced quite that way, now 16:45:16 eglute: yes, thanks 16:45:27 anything else on microversions? 16:46:17 I suggest gwtting matt reidmann involved for details 16:46:35 #topic Scoring 2018.01 guideline 16:46:48 any updates on nova? 16:46:52 he'll be happy to help and nova is steeped the deepest in this 16:47:31 Rockyg I think he already should be helping Howard with nova 16:48:01 though I dont think Howard is attending this meeting today, might have something to do with that national holiday :) 16:48:26 unless Rockyg you have update from him? 16:49:19 lets move to cinder 16:49:29 thanks mguiney for submitting patch! 16:49:39 #link https://review.openstack.org/#/c/509337/ 16:49:43 yup! 16:50:21 theres a few changes, actually, that I want to make to the swift one, so i'm sure there will be more to talk about that then :P 16:50:28 looks like no new capabilities will get added- would that change with microversions? 16:50:42 for swift or cinder? 16:50:47 cinder 16:51:18 ah, there actually is one added 16:51:47 yes, but it didnt score high enough? 16:51:55 right right 16:51:58 volumes-v3-snapshot-revert? 16:52:06 cool! 16:52:10 yeah, 50 no good ;-) 16:52:27 still, scores can rise with releases 16:52:34 agreed! 16:52:45 thanks mguiney for scoring it :) 16:53:02 i'll take a another look to make sure that's a scoring for the capability, and then push another patch if im not confident about the decision 16:53:07 everyone, please review the cinder scoring patch and comment 16:53:21 #link https://review.openstack.org/#/c/509337/ 16:53:35 if nothing else on cinder, we can move to swift 16:53:43 thanks mguiney again :) 16:54:10 Everyone, please review and comment: #link https://review.openstack.org/#/c/507347/ 16:54:26 I need to review this as well 16:54:35 but also looks like no new additions, correct? 16:54:40 well 16:54:55 so there has been some debate about large object coverage 16:55:03 oh? 16:55:45 apparently dynamic large objects are covered by interop guidelines but static ones are not, and some clouds using swift that use Static large objects cannot pass as a result 16:56:34 so what has been suggested? 16:56:38 the dynamic large objects test is built into another test that is required, so it's a default which causes the static-using clouds to run into problems 16:56:39 mguiney: pedantic note, some may not also support static large objects. all will support dynamic 16:56:48 notmyname: I don't fully understand it, but it seems like a gap we need to fill 16:57:06 notmyname: thank you 16:57:07 yep, that's why i assumed that it was built into another test 16:57:17 yes thank you 16:57:23 understanding still faulty 16:58:12 but getting better thanks to notmyname 16:58:12 IMO all swifts should have static large objects enabled (it's pretty much assumed everywhere, eg glance), and we (dev community) seem to be in favor of forcing it on always 16:58:41 notmyname: so we should be considering dynamic large objects as a new distinct capability, correct? 16:58:58 but the current thought is to perhaps break dynamic large objects into their own capability 16:59:08 yep, slow fingers my bad 16:59:10 I think that phrasing makes me cringe a little, because DLOs have been in swift for years and years 16:59:28 well, new required capability for interoperability 16:59:50 but given that reality, my habit is to defer to your team for the best way to organize it for your tools 17:00:02 IMO all swifts everywhere should support both DLOs and SLOs 17:00:03 hogepodge, ++ not new, but tests that separately validate 17:00:37 mguiney perhaps you could work with notmyname on proposing "new" capability for interop guideline? 17:00:52 I thnk we're all out of time...may need to continue on #openstack-interop 17:00:54 o7 17:00:57 quickie on nova...no update and yes, holiday. I;ll sync with howard 17:01:00 unfortunately we are out of time today 17:01:01 can do 17:01:06 thanks Rockyg 17:01:24 thanks everyone! interop irc channel is always open! :) 17:01:28 #endmeeting