19:01:20 <catherineD> #startmeeting refstack
19:01:21 <openstack> Meeting started Tue Aug  9 19:01:20 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:24 <openstack> The meeting name has been set to 'refstack'
19:02:22 <pvaneck> o/
19:03:48 <andrey-mp> o/
19:04:11 <catherineD> #link meeting agenda and notes,  https://etherpad.openstack.org/p/refstack-meeting-16-08-09
19:05:27 <catherineD> I guess we will have a samll group today
19:05:31 <catherineD> small
19:05:53 <catherineD> #topic DefCore Midcycle RefStack related discussion
19:06:10 <catherineD> #topic Introduce target_programs definition
19:06:36 <catherineD> andrey-mp: so the defcore team spend some time discussing this patch during the meeting
19:07:32 <catherineD> the recomendation is to have both DefCore and RefStack team co-author this patch so that it will cover view from both teams ...
19:07:48 <andrey-mp> ok
19:08:07 <catherineD> andrey-mp: do you mind if Chris co-author this patch with you?
19:08:15 <andrey-mp> I'm ready for comments (or additional explanation from DefCore)
19:08:26 <andrey-mp> I don't mind
19:09:28 <hogepodge> o/
19:09:30 <catherineD> The foundation is actually thinking about sometime of "mixin" target program ... hogepodge: can tell you more ...
19:10:13 <hogepodge> If we're going to do a major version bump of the guideline we want to try and build it to meet future goals
19:10:22 <catherineD> hogepodge: do you mind co-auther with andrey-mp: on https://review.openstack.org/#/c/310621/  ? andrey-mp: do not mind for that
19:10:50 <hogepodge> So we want to keep the idea of components, and break these out so they can be independently defined
19:11:48 <hogepodge> Then have a higher level abstraction of programs that are composed of components (in the case of major target programs), or can be defined to require other components (in the case of mixins)
19:11:52 <andrey-mp> sure. with this scheme we can do it as I understand
19:12:18 <hogepodge> As part of this, we would encourage big tent projects to start defining their own interoperability components.
19:12:51 <hogepodge> I need to write up the design from the defcore mid-cycle
19:13:01 <catherineD> andrey-mp: hogepodge: may I suggest that you two work to gether and co-author the patch to make sure that it will meet the needs for both DefCore and RefStack team
19:13:07 <andrey-mp> ok
19:13:27 <hogepodge> we're not just going to approve a major version bump in the defcore project without having gone through a design process, we did a lot of that work in the mid-cycle. So the patch is a good start
19:13:29 <andrey-mp> here is an example of our EC2 guideline - https://github.com/cloudscaling/refstack-guidelines/blob/master/aws.json
19:13:45 <andrey-mp> (based on this scheme)
19:13:48 <hogepodge> We also are going to require a lot of side materials to go with it, including documentation.
19:14:52 <andrey-mp> We thought that target_programs will define programs like compute, object store, or program that includes both
19:15:07 <andrey-mp> ok, I don't mind )
19:15:30 <andrey-mp> scheme itself is not well documented
19:15:45 <hogepodge> andrey-mp: if you want, I can submit a change on top of the patch that captures what we talked about in San Antonio
19:15:58 <andrey-mp> sure
19:16:11 <hogepodge> we can iterate on that
19:16:35 <andrey-mp> it's good
19:16:48 <catherineD> #action hogepodge: and andrey-mp: to work on new Guideline schema
19:16:58 <catherineD> moving on to the next topic ...
19:17:28 <catherineD> #topic Replace the term "certification" by  "validated"
19:17:53 <catherineD> This is the recommendation from DefCore and Foundation
19:18:07 <andrey-mp> ok
19:18:17 <catherineD> moving on ...
19:18:32 <catherineD> #topic Product model
19:18:46 <andrey-mp> this will be changed in spec first?
19:19:06 <catherineD> andrey-mp: yes..
19:19:13 <hogepodge> catherineD: on the last topic, we're doing that because certification has legal meaning that we don't want to imply
19:19:34 <catherineD> hogepodge: thx ...
19:19:45 <catherineD> #link     See slide 6 & 7 of https://docs.google.com/presentation/d/1btnlXcCoucjbmUNd18QoPK68UNuNLN9oFvUBWtYgATo/edit#slide=id.g162312dc03_1_36
19:20:03 <catherineD> andrey-mp: thank for your review to the slides
19:20:09 <catherineD> and post questions
19:20:30 <catherineD> question#1: Certification flag is used only for distro. Does DefCore want to certificate clouds (public or private) int the future?
19:20:56 <catherineD> Answer: Certification (soon to be verification) flag is used only for all OpenStack Foundation defined products (distro/appliance, hosted private cloud, public cloud)
19:21:02 <hogepodge> catherineD: I don't understand, why wouldn't it apply to public or private clouds?
19:21:43 <catherineD> hogepodge: it does ... that is the question from andrey-mp: to us ... I just type the answer
19:22:19 <andrey-mp> so, slide 6 should be changed?
19:23:02 <catherineD> yes .. slide 5 is the database table model we have today
19:23:39 <catherineD> slide 7 is my suggestion to change ... that we can discuss here
19:23:45 <sslypushenko> o/
19:23:53 <catherineD> but before that I want to review slide 6
19:24:22 <catherineD> sslypushenko: hi thx for joining .. we discuss slide 5 - 7 on https://docs.google.com/presentation/d/1btnlXcCoucjbmUNd18QoPK68UNuNLN9oFvUBWtYgATo/edit#slide=id.g162312dc03_1_36
19:24:40 <catherineD> let's look at slide 6
19:24:44 <sslypushenko> Hi! got it)
19:25:24 <catherineD> As discussed in DefCore midcycle ... a product may have zero or many version ...
19:25:43 <catherineD> For example: public cloud will have no version
19:26:07 <catherineD> so the relationship from product to versio is 1 to 0..n
19:26:16 <andrey-mp> i like definition that public cloud has one version always
19:26:43 <sslypushenko> catherineD:  It looks like Defcore should provide more clear vision in some kind of document. Because now it looks weird... a bit
19:26:53 <catherineD> andrey-mp: I know we like that ... but that is not what DefCore and Foundation's model
19:27:51 <catherineD> sslypushenko: I am not sure what to say ... but everyone could have join the midcycle meeting?
19:27:59 <hogepodge> andrey-mp: sslypushenko: it's not so much we say 'public has only one version' and 'distro can have many', rather it's an attempt to capture the variety of deployment models out there. Most public clouds don't advertise a version, but all distros do
19:28:52 <sslypushenko> hogepodge: catherineD: it is clear... but the problem is that is not whole picture
19:29:06 <catherineD> so giving the business model we need to model based on that
19:29:57 <catherineD> sslypushenko: maybe hogepodge: could help with answering the whole picture questions?
19:29:57 <sslypushenko> to many places looks unclear and it definitely not RefStack team zone of responsibility to fill these places
19:30:34 <hogepodge> I have to understand the question
19:31:12 <andrey-mp> hodepodge - 1. is public clouds based on distro with specific version?
19:31:46 <sslypushenko> Basically, I'd love to see Defcore's vision of business model
19:32:00 <andrey-mp> 2. when public cloud introduce new service/functionality - how we can treat this process?
19:32:41 <hogepodge> andrey-mp: 1. that information is opaque to user, and it's up to the public cloud to report what they want to report
19:32:59 <andrey-mp> I agree with ssplypushenko - I think that most of our question was discussed and documented
19:33:14 <hogepodge> andrey-mp: 2. again, it's up to the cloud. if they want to version, they can. If they want to submit new test results that show the additional functionality, they can
19:33:48 <andrey-mp> so it means that public (and private) clouds can have version too
19:33:50 <hogepodge> I don't see how the vision isn't captured in the database model
19:33:57 <hogepodge> andrey-mp: yes
19:34:06 <andrey-mp> -> all product can have version
19:34:17 <andrey-mp> -> distro's must have version
19:34:26 <catherineD> andrey-mp: andrey-mp: I agree and would love to have document too ... but we should not stop because of no document
19:34:26 <hogepodge> andrey-mp: or not if they don't want to. I don't care if they do or don't, and this model captures that
19:35:03 <sslypushenko> hogepodge:  it is really far from being captured
19:35:20 <catherineD> andrey-mp: from RefStack model ... all product will have at least one version ... for public cloud the version name can be blank
19:35:22 <andrey-mp> catherineD: we can do all. but withour clear vision we will re-do most code twice )
19:35:56 <catherineD> andrey-mp: sslypushenko:  Paull has added a prototype at http://refstack.mybluemix.net/#/
19:36:05 <sslypushenko> andrey-mp:  actually not twice, it is our second  try)
19:36:09 <andrey-mp> catherineD: where we can see it there?
19:36:20 <catherineD> the vision for what we want to achieve is on http://refstack.mybluemix.net/#/community_results
19:37:45 <andrey-mp> whats new there? (I don't understand field 'status')
19:37:48 <catherineD> that is the page and information we want to achieve ... the rest are supporting artifacts for us to get to display the information on this page
19:38:41 <catherineD> what is new is the additional information to this https://refstack.openstack.org/#/community_results
19:38:57 <andrey-mp> vendor/product - it's ok. status/verified - what is it?
19:39:18 <catherineD> andrey-mp: status --> is the pass/fail based on the guideline version adn target program
19:39:32 <hogepodge> andrey-mp: if OSF has marked a product as verified according to the board approved guideline
19:39:54 <catherineD> andrey-mp: verified is the previous certification column
19:40:36 <andrey-mp> -> verified - is a flag that is set by foundation admin for specific test result ?
19:40:52 <hogepodge> andrey-mp: yes
19:41:04 <andrey-mp> ok
19:41:31 <sslypushenko> looks... strange
19:41:35 <catherineD> andrey-mp: sslypushenko: do you see the vision where we want to achieve for the newton cycle ?
19:42:00 <catherineD> sslypushenko:  where pls?
19:42:37 <sslypushenko> I don't think that 'verified' needs to be displayed by default
19:42:43 <andrey-mp> catherineD: no ) I see what we want in general but not to Newton
19:43:13 <sslypushenko> 99.99% results will be not verified
19:43:33 <catherineD> sslypushenko: I am open for the ... hogepodge: your thought should we display the verified flag on the http://refstack.mybluemix.net/#/community_results page?
19:44:16 <catherineD> andrey-mp: that page is the specific target I would like RefStack  to provide in the Newton cycle
19:44:19 <sslypushenko> catherineD:  I don't have strong opinion in this... maybe I lost some part of picture
19:44:42 <hogepodge> catherineD: sslypushenko: getting that flag set and visible to users is a major goal of this program
19:44:49 <catherineD> sslypushenko: correct 99% fo the results will not be certified
19:44:51 <sslypushenko> answering on your question on RefStack is the answer is yes and no)
19:45:27 <catherineD> sslypushenko: ?
19:45:29 <hogepodge> so displaying it is important when showing the results, it's an immediate visual indicator of an important result, all the more important by the infrequency of it
19:46:01 <catherineD> oh ..ic yes --> means verifed ... no means not verified
19:46:21 <catherineD> maybe it is not intuitive with yes/no?
19:46:25 <andrey-mp> catherineD: your main goal is a new community_results page?
19:46:32 <sslypushenko> hogepodge: I guess filter for displaying only certified results will be much more helpful for users)
19:47:05 <catherineD> andrey-mp: goal is to support displaying on those information on the community_result page ..
19:47:09 <sslypushenko> As I already told - I don't have strong opinion on UI
19:47:34 <hogepodge> sslypushenko: sure, a filter is good too. I'd be happy with both
19:48:04 <andrey-mp> catherineD: support displaying - is an API efforts only ) but we need and displaying too
19:48:04 <catherineD> #action Add feature to filter fetching of verified results
19:48:16 <sslypushenko> catherineD:  thx)
19:48:31 <catherineD> andrey-mp: this PoC have both API and UI ...
19:48:41 <hogepodge> andrey-mp: the community results page as it is right now has no information. It's random strings with links to actionable data, but you can't know if the data is important until you follow the link right now
19:48:56 <catherineD> but the first thing we need to do is with the goal we want to achieve ... agree on data model
19:49:24 <catherineD> now that we know our goal we can go back and discuss the data model
19:49:24 <andrey-mp> hogepodge: I agree that this page is not so informative
19:50:22 <andrey-mp> catherineD: I've asked about clouds (version and verified flag) because I want to understand how to make data model correctly
19:50:32 <sslypushenko> catherineD:  I meant it is clear that RefStack should move on in direction on aggregation test results data but from now it is clear that our try to align business and data models is going to fail
19:50:41 <catherineD> andrey-mp: sure sure ... pls do ask questions //
19:50:57 <andrey-mp> I've asked - it was my first question
19:51:07 <catherineD> sslypushenko: why would it fail?
19:51:36 <sslypushenko> data model becomes more and more complicated...  it is sign that we are doing something wrong
19:51:57 <catherineD> andrey-mp: I think both hogepodge: and I answer that  the verification is for all public cloud, distor, hosted private cloud
19:52:01 <hogepodge> sslypushenko: you can't say things like "it's clear that" without actually making an argument as to why. This model didn't come out of thin air, and we've offered an explanation of it,
19:52:34 <catherineD> sslypushenko: either we do something wrong or we are more aligne with reality?
19:53:17 <sslypushenko> hogepodge:  can you please provide a link on document with such explanation?
19:53:37 <catherineD> sslypushenko: the fact is foundation definition is a product may have zero or many versions ... it is up to us to model this definition
19:53:55 <hogepodge> sslypushenko: These meeting minutes for starters? Exactly what do you want me to describe?
19:54:24 <hogepodge> 1) A product can have one to many versions.
19:54:36 <hogepodge> 2) A test result is associated with a version of a product.
19:54:37 <andrey-mp> catherineD: if so - how verified flag can be applied to clouds? (through the cloud? and cloud must have link to product? or to product+version?)
19:55:01 <hogepodge> 3) A version may have many test results.
19:55:02 <sslypushenko> hogepodge:  catherineD: don't get me wrong... I don't have clear understanding how we can fix current issues... Just want to share my feelings
19:55:26 <hogepodge> 4) The result of the test is what is verified by the OSF as meeting the requirements for the OpenStack Powered program.
19:55:40 <catherineD> andrey-mp: we do not have cloud table in RefStack ... all we have is product table ... so a public cloud is just a product  (an entry in the product table)
19:56:12 <hogepodge> 5) This is to capture many use cases, including required annual renewal of public clouds and required renewals of product version bumps
19:56:31 <andrey-mp> hogepodge: is it right that test result can be associated with product+version of some Cloud?
19:56:36 <catherineD> sslypushenko: I understand ... that is why I would always like to have you on this type of discussion ... and I appreciate it very much!
19:57:12 <andrey-mp> (I mean situation when product is a public cloud)
19:57:56 <sslypushenko> hogepodge: First of all we need to clarify all usecases we want to cover and goals we want to achive
19:58:06 <catherineD> andrey-mp: take a look at this page https://www.openstack.org/marketplace/public-clouds/   this are the public cloud product
19:58:15 <hogepodge> andrey-mp: all products will have at least one version, even if the version identifier is empty, so yes. Because only one product can be associated with a version, the test result application is transitive. result -> version -> product
19:58:15 <sslypushenko> and put it on some kind of spec
19:58:32 <catherineD> sslypushenko: that is exatly what I want to do here
19:58:40 <catherineD> have this discussion then put them in a spec
19:58:50 <andrey-mp> hogepodge: thanks
19:58:54 <catherineD> I could have put them on a spec first
19:58:59 <sslypushenko> catherineD:  that is good)
19:59:30 <catherineD> I will add all we discuss here on the spec ...
19:59:42 <catherineD> we are out of time
19:59:47 <andrey-mp> catherineD: this is slide 6. it assumes that test result linked only to cloud
19:59:57 <catherineD> let's move to #refstack
20:00:04 <catherineD> #endmeeting