16:00:25 <eglute> #startmeeting interopwg
16:00:26 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:29 <openstack> The meeting name has been set to 'interopwg'
16:00:44 <eglute> Hello Everyone!
16:00:53 <mguiney> o/
16:00:54 <georgk> hi
16:00:54 <eglute> #chair markvoelker hogepodge
16:00:54 <openstack> Current chairs: eglute hogepodge markvoelker
16:00:59 <eglute> #topic agenda
16:01:02 <eglute> #link https://etherpad.openstack.org/p/InteropVertigo.17
16:01:08 <eglute> please update agenda as needed!
16:01:44 <eglute> Hope everyone is doing well today
16:01:58 <eglute> markvoelker said he might not be able to join us today
16:02:18 <eglute> anyone else here for the interop meeting?
16:02:36 <hogepodge> I'm here, but have a conflicting meeting so won't be fully present
16:02:49 <eglute> thanks hogepodge
16:03:05 <hogepodge> I have some thoughts about microversions though, that I'll need to work through
16:03:36 <eglute> hogepodge will you time in todays meeting to share your thoughts?
16:03:52 <eglute> we can start with that if it would help or do it at a specific time
16:04:27 <eglute> #topic OpenStack Summit Sydney
16:04:38 <eglute> If there are any additional sessions, please add them
16:05:04 <eglute> I still need to have myself removed from the session listed, since I won't be attending this summit.
16:05:21 <eglute> #action eglute to get herself removed from the summit session
16:06:02 <eglute> #topic Vertical Program Update
16:06:18 <mrhillsman> o/
16:06:30 <eglute> thank you georgk for creating that google spreadsheet
16:06:37 <eglute> #link https://docs.google.com/spreadsheets/d/1mvjo82eFsXwG-IOMfVVnGPNbNHRuOQPgxH1EtIpRuUg/edit#gid=0
16:07:04 <georgk> well, it is an attempt. it feels like more details would be needed
16:07:10 <eglute> everyone, if you are familiar with OPNFV, please review and provide feedback to georgk
16:07:33 <catherineD> o/
16:08:17 <hogepodge> well my time freed up so I can talk now :-D
16:08:20 <eglute> georgk that spreadsheet looks like it already took a lot of work
16:08:48 <eglute> great hogepodge! are you free for the rest of the hour?
16:09:37 <eglute> georgk one quick note- Ceph is not part of openstack, thought they are used together often!
16:10:02 <georgk> eglute: true, noted
16:10:22 <eglute> some of the other projects i am not sure, since there are so many under openstack right now
16:10:55 <georgk> i need to go through it once more
16:10:56 <eglute> georgk markvoelker any other updates on the vertical programs?
16:11:36 <georgk> one take away is anyway that functionatlity worked on by OPNFV is likely not present in commercial products now
16:12:07 <georgk> I´d like to get the scoring started, but I might need a bit of advise
16:12:19 <georgk> maybe I´ll ping you on IRC in the next days
16:12:26 <eglute> can you elaborate on that georgk
16:12:57 <georgk> eglute: on the scoring?
16:13:14 <eglute> no, on the "OPNFV is likely not present in commercial products now"
16:13:37 <eglute> do you expect that OPNFV will be using in commercial products? or?
16:14:54 <georgk> 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 <georgk> 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 <georgk> hence, not yet widely deployed enough for inclusion in the vertical
16:16:25 <eglute> georgk that makes sense, thank you
16:17:05 <eglute> georgk markvoelker anything else on verticals?
16:17:13 <markvoelker> 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 <markvoelker> 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 <markvoelker> (it's a national holiday week in China)
16:19:16 <mguiney> huh. interesting
16:19:28 * eglute wishes for a week of holidays
16:20:04 <eglute> markvoelker hogepodge any ideas of commercial openstack deployments that use NFV/OPNFV?
16:23:09 <eglute> i take that as a no :)
16:23:12 <Rockyg> o/
16:23:15 <markvoelker> 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 <hogepodge> 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 <eglute> thanks markvoelker and hogepodge
16:23:57 <eglute> hogepodge can you talk on microversions now?
16:24:03 <eglute> #topic microversions
16:24:04 <markvoelker> 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 <eglute> thanks markvoelker! didnt mean to cut you off with topic change
16:24:46 <markvoelker> no worries
16:25:02 <eglute> markvoelker anything else on nfv?
16:25:29 <hogepodge> eglute: yes
16:25:46 <markvoelker> nope, I'm done
16:25:47 <hogepodge> I'm trying to work out technically how to express microversions.
16:26:01 <eglute> thanks markvoelker
16:26:36 <hogepodge> 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 <eglute> hogepodge how does testing work now with microversions?
16:27:04 <hogepodge> because it should apply globally, but have the option to have additional information in the capability
16:27:22 <hogepodge> eglute: for each project you can configure tempest to have a min and max version
16:27:52 <markvoelker> 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 <markvoelker> So is our intent here to be more explicit for people's edification, or...?
16:28:50 <hogepodge> markvoelker: the worry is that we could be testing head which uses a microversion not available in older releases
16:29:46 <markvoelker> 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 <markvoelker> And we know (or can determine) when various microversions were introduced...
16:30:59 <hogepodge> tempest might need to be configured to limit a version, though
16:31:15 <hogepodge> folks with more experience in running and testing microversions might be able to say more
16:31:56 <markvoelker> Ok, so the major concern is helping people configure tempest to test something appropriately?
16:32:01 <eglute> could we require only a minimum micro version?
16:33:22 <hogepodge> markvoelker: yes, and setting clear expectations
16:33:42 <Rockyg> 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 <hogepodge> to vendors, to users
16:34:13 <markvoelker> 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 <Rockyg> So, fo testing, requiring the minumum and having tests that exercise the current max is needed
16:34:35 <hogepodge> markvoelker: it's the source of all truth for interop
16:34:46 <markvoelker> 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 <Rockyg> Ooh!  I didn't know that!
16:35:43 <markvoelker> 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 <hogepodge> microversions are on the critical path for current scoring though, as I understand it
16:36:52 <Rockyg> So, we need to have a way to *identify* microversions valid in the schema, but not necessarily the tempest configs.
16:37:33 <hogepodge> 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 <eglute> hogepodge how about expressing only a minimum?
16:38:28 <markvoelker> 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 <hogepodge> eglute: but what if a capability changes with a version? I don't know how versioning policy works.
16:38:44 <markvoelker> The tempest config then remains the possible issue though
16:39:27 <eglute> hogepodge ack, good point.
16:39:48 <Rockyg> versioning policy is that any time you have a backward incompatible change, you need a new microversion
16:39:54 <hogepodge> markvoelker: so we could introduce metadata on the capability that indicates which microversion introduced it?
16:40:09 <Rockyg> but you also need the code to allow the old stuff to work.
16:40:32 <Rockyg> hogepodge, yes.
16:40:47 <markvoelker> hogepodge: that's kinda what I'm thinking.  An optional field that lists the microversion needed as a heads-up.
16:41:27 <hogepodge> ok, that gives me some direction to work with
16:42:05 <hogepodge> Thanks. mguiney and I were thinking about it the other day, but this is good guidance
16:42:09 <eglute> +1
16:42:32 <markvoelker> Rockyg: actually backward-breaking changes are what drive a bump in the major version number, not the minor one.
16:42:48 <markvoelker> #link https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html Microversion Specification (if folks need a reference)
16:43:04 <eglute> thanks markvoelker
16:44:58 <eglute> hogepodge do you have enough to go on?
16:45:02 <Rockyg> I'm thinking that that might be not be being enforced quite that way, now
16:45:16 <hogepodge> eglute: yes, thanks
16:45:27 <eglute> anything else on microversions?
16:46:17 <Rockyg> I suggest gwtting matt reidmann involved for details
16:46:35 <eglute> #topic Scoring 2018.01 guideline
16:46:48 <eglute> any updates on nova?
16:46:52 <Rockyg> he'll be happy to help and nova is steeped the deepest in this
16:47:31 <eglute> Rockyg I think he already should be helping Howard with nova
16:48:01 <eglute> though I dont think Howard is attending this meeting today, might have something to do with that national holiday :)
16:48:26 <eglute> unless Rockyg you have update from him?
16:49:19 <eglute> lets move to cinder
16:49:29 <eglute> thanks mguiney for submitting patch!
16:49:39 <eglute> #link https://review.openstack.org/#/c/509337/
16:49:43 <mguiney> yup!
16:50:21 <mguiney> 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 <eglute> looks like no new capabilities will get added- would that change with microversions?
16:50:42 <mguiney> for swift or cinder?
16:50:47 <eglute> cinder
16:51:18 <mguiney> ah, there actually is one added
16:51:47 <eglute> yes, but it didnt score high enough?
16:51:55 <mguiney> right right
16:51:58 <eglute> volumes-v3-snapshot-revert?
16:52:06 <eglute> cool!
16:52:10 <hogepodge> yeah, 50 no good ;-)
16:52:27 <hogepodge> still, scores can rise with releases
16:52:34 <eglute> agreed!
16:52:45 <eglute> thanks mguiney for scoring it :)
16:53:02 <mguiney> 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 <eglute> everyone, please review the cinder scoring patch and comment
16:53:21 <eglute> #link https://review.openstack.org/#/c/509337/
16:53:35 <eglute> if nothing else on cinder, we can move to swift
16:53:43 <eglute> thanks mguiney again :)
16:54:10 <eglute> Everyone, please review and comment: #link https://review.openstack.org/#/c/507347/
16:54:26 <eglute> I need to review this as well
16:54:35 <eglute> but also looks like no new additions, correct?
16:54:40 <mguiney> well
16:54:55 <mguiney> so there has been some debate about large object coverage
16:55:03 <eglute> oh?
16:55:45 <mguiney> 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 <eglute> so what has been suggested?
16:56:38 <mguiney> 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 <notmyname> mguiney: pedantic note, some may not also support static large objects. all will support dynamic
16:56:48 <hogepodge> notmyname: I don't fully understand it, but it seems like a gap we need to fill
16:57:06 <hogepodge> notmyname: thank you
16:57:07 <mguiney> yep, that's why i assumed that it was built into another test
16:57:17 <mguiney> yes thank you
16:57:23 <mguiney> understanding still faulty
16:58:12 <Rockyg> but getting better thanks to notmyname
16:58:12 <notmyname> 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 <hogepodge> notmyname: so we should be considering dynamic large objects as a new distinct capability, correct?
16:58:58 <mguiney> but the current thought is to perhaps break dynamic large objects into their own capability
16:59:08 <mguiney> yep, slow fingers my bad
16:59:10 <notmyname> I think that phrasing makes me cringe a little, because DLOs have been in swift for years and years
16:59:28 <hogepodge> well, new required capability for interoperability
16:59:50 <notmyname> 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 <notmyname> IMO all swifts everywhere should support both DLOs and SLOs
17:00:03 <Rockyg> hogepodge, ++ not new, but tests that separately validate
17:00:37 <eglute> mguiney perhaps you could work with notmyname on proposing "new" capability for interop guideline?
17:00:52 <markvoelker> I thnk we're all out of time...may need to continue on #openstack-interop
17:00:54 <mguiney> o7
17:00:57 <Rockyg> quickie on nova...no update and yes, holiday.  I;ll sync with howard
17:01:00 <eglute> unfortunately we are out of time today
17:01:01 <mguiney> can do
17:01:06 <eglute> thanks Rockyg
17:01:24 <eglute> thanks everyone! interop irc channel is always open! :)
17:01:28 <eglute> #endmeeting