19:00:45 <catherineD> #startmeeting refstack
19:00:46 <openstack> Meeting started Tue Jul 19 19:00:45 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:50 <openstack> The meeting name has been set to 'refstack'
19:01:23 <pvaneck> o/
19:02:27 <hogepodge> o/
19:03:09 <catherineD> hello Sergey is on vacation for the next 2 weeks
19:03:25 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-07-19
19:04:06 <catherineD> it maybe a quick meeting today
19:04:11 <catherineD> #topic Mascot for RefStack
19:04:51 <catherineD> #link https://etherpad.openstack.org/p/refstack-mascot
19:05:09 <catherineD> hogepodge: thanks for the inputs ...
19:05:32 <hogepodge> Since refstack is a collection of test results sent in by users in our community, I feel that the client-server and collaborative aspects are well represented by a honey bee
19:05:36 <catherineD> I really like option 1
19:05:38 <hogepodge> And perhaps a hive
19:05:42 <pvaneck> I like the honey bee idea as well
19:05:51 <andrey-mp> o/
19:05:54 <pvaneck> when is the dead line for mascots
19:06:03 <catherineD> Jul 27
19:06:22 <pvaneck> ah just saw
19:06:27 <catherineD> andrey-mp:  https://etherpad.openstack.org/p/refstack-meeting-16-07-19
19:07:03 <rockyg> o/
19:07:49 <catherineD> let vote for the 2 options in https://etherpad.openstack.org/p/refstack-mascot
19:08:27 <catherineD> unless there is other inputs
19:09:10 <rockyg> Uh, I didn't know about this etherpad until now....
19:09:32 <rockyg> I'd like a little time to think on this.
19:09:45 <pvaneck> can revisit next week
19:09:47 <catherineD> fair enougn ... we can postpone voting to next week
19:10:26 <rockyg> Maybe we can come up with more contenders for the mascot
19:10:28 <catherineD> please add your ideas to the etherpad ...
19:11:12 <catherineD> we can vote next week ...
19:11:17 <catherineD> moving on ...
19:11:47 <catherineD> #topic Using refstack-client to update product table product_ref_id
19:12:13 <catherineD> #link Authenticate user for update product with public key and signature  (  https://review.openstack.org/#/c/335877/  )
19:13:09 <catherineD> andrey-mp: there are concerns about key/sign implementation that this patch expose ...
19:13:09 <andrey-mp> this is a varios links...
19:13:50 <catherineD> andrey-mp: ?
19:13:52 <andrey-mp> this patch uses same auth method as results post method
19:14:07 <andrey-mp> topic about refstack-client and link about refstack API
19:15:03 <catherineD> andrey-mp: the topic would include both server and client side ...
19:15:38 <andrey-mp> ok
19:16:10 <andrey-mp> but this is two different topic/issues (for me)
19:17:03 <pvaneck> catherineD: you said there are concerns?
19:17:04 <catherineD> I am OK if we discuss the client side first?
19:17:27 <catherineD> concerns on the server side ... but for now let's discuss the client side
19:17:33 <andrey-mp> ok
19:17:37 <catherineD> we will come back to the server side
19:18:07 <catherineD> #link Add register cloud command ( https://review.openstack.org/#/c/335883/ )
19:19:48 <catherineD> in general, this patch should only be merged if the server side provides such function to allow command (PUT in this case) with X-Publickey ... in the header
19:19:59 <andrey-mp> sure
19:20:14 <catherineD> I know that https://review.openstack.org/#/c/335883/ is depending on https://review.openstack.org/#/c/335877/
19:20:27 <catherineD> but https://review.openstack.org/#/c/335877/ will be merged to feature/vendor
19:20:49 <andrey-mp> but in general you should decide about this functionality at all - does refstack need it or not
19:21:34 <catherineD> andrey-mp: I don't mind to have this function ... it is one way to initialize the product_ref_id
19:21:39 <catherineD> I am OK with it
19:22:48 <catherineD> I can +2 but just do not want us to accidentally merge it ..
19:23:13 <catherineD> pvaneck: do you have a chance to review this patch?
19:23:35 <andrey-mp> some time ago we suggested to link results and clouds via this property. and if decision will be changed about linking results to products then this patchset is not needed...
19:24:38 <catherineD> andrey-mp: I see your concern that is topic #5 for today's discussion  ..
19:24:58 <pvaneck> catherineD, havent tested it yet, and yea, we'll have to come to a resolution regarding the product-test link
19:25:21 <catherineD> regardless product_ref_id can still be initallize with cloud id  .. that is why I think the patch is still work for me
19:25:42 <andrey-mp> catherineD: yes, it is.
19:27:10 <catherineD> in that case let's go directly to topic #5 ... but before that since rockyg: hogepodge: are here I want to touch base on topic 4.2 really quick
19:27:25 <catherineD> #topic Specification for marking a record as "used for certification"
19:28:04 <catherineD> In last week's meeting, the team has decided to split out the specification for certification section from  https://review.openstack.org/#/c/332260/
19:28:49 <catherineD> rockyg: hogepodge: please review https://review.openstack.org/#/c/343954/
19:29:13 <catherineD> pvaneck: andrey-mp: please review .. especially the API section in https://review.openstack.org/#/c/343954/
19:29:14 <rockyg> looking at it now...
19:29:23 <andrey-mp> catherineD: I agree with Alex - it is simplier to have one action with parameter.
19:29:36 <catherineD> andrey-mp: did you see my response?
19:29:55 <andrey-mp> yes
19:30:04 <catherineD> also take a look at the vendor API on the action section ...
19:31:49 <catherineD> andrey-mp: pvaneck: please add you feedback regarding the API in the review ... I am willing to update ...I am willing to follow the majority's opinions
19:32:13 <pvaneck> sure
19:32:34 <rockyg> Couple of thoughts.  Rather than boolean, I wonder if Chris might want an identifier that ties the test result into the foundation records.  Identifier=certified.  nil=no cert
19:32:38 <hogepodge> The api will need a way to handle association of guidelines to anonymous results.
19:32:38 <catherineD> for that .. everyone please add your review to the patch
19:33:37 <catherineD> hogepodge: technically since the result is anonymous that means that no one owns them
19:33:52 <catherineD> of course , foundation own everything ...
19:34:01 <rockyg> Also, there may be multiple different logos going forward.  We already have 3
19:34:30 <catherineD> so  interop admins can assiciate result to guideline
19:34:44 <rockyg> so, some sort of prefix to identify which cert is also a good thing:  prefix+certID
19:35:16 <catherineD> rockyg: yea good point
19:35:31 <catherineD> hogepodge: what do you think?
19:35:55 <rockyg> And maybe prefix+foundation-Anon-ref+certID
19:36:13 <rockyg> Or something like that.  hogepodge, what do you think?
19:36:20 <catherineD> rockyg: preferly this column will be a number for sorting and selecting
19:36:40 <catherineD> so it would be constant with definition of different kind
19:37:39 <catherineD> hogepodge: that means that when interop admin mark as certified ... interop admins need to choose from a list of certification types
19:38:26 <catherineD> hogepodge: what do you think?
19:39:43 <hogepodge> catherineD: what do you mean types?
19:40:41 <hogepodge> Oh, platform, compute, and storage
19:41:03 <catherineD> something like 1=Openstack Platform, 2=compute 3=object
19:41:13 <catherineD> instead of true/false
19:41:32 <hogepodge> Sure, it allows for expansion. I'd break them out though, and have the types be a set
19:41:33 <catherineD> we define constants for the various types
19:41:40 <catherineD> great
19:41:51 <catherineD> rockyg: thanks for the idea
19:41:59 <catherineD> I will make update ...
19:42:05 <hogepodge> The issue being, we're going to propose expanding the program to include something like mixins, so you could have OpenStack Powered Compute with Heat.
19:42:11 <andrey-mp> catherineD: as i remember - result contains a program? why do you need one more number? what if one more programm will be added?
19:42:42 <hogepodge> Just in the proposal stage, but it's how we're thinking about how to account for big tent and other projects that with an OpenStack Powered cloud
19:43:11 <catherineD> hogepodge: in that case we just define a different constant for OpenStack Powerd Compute with Heat
19:43:44 <rockyg> maybe hogepodge can propose something that at least meets the foundation thinking and put it in as a comment to be added or?
19:43:47 <hogepodge> But it's going to grow combinatorially. Add Heat, Trove, Ceilometer, Sahara...
19:43:52 <catherineD> andrey-mp: we just define additional constant for new program
19:44:54 <andrey-mp> but why refstack can't use link to a program/guideline from result?
19:45:23 <catherineD> andrey-mp: we do
19:45:27 <andrey-mp> why it needs duplicate information stored as unusual way?
19:45:53 <catherineD> today, you can assiciate result to a guideline and program
19:46:55 <catherineD> andrey-mp: because even that the result is linked to guideline and program , it does not mean that it is used as official certified result
19:47:07 <catherineD> andrey-mp: so it is not duplicate
19:47:11 <hogepodge> A result being used for certification is independent of the program/guideline. If those are fields that already exist, then I'm not sure that much more than a boolean is needed
19:47:43 <andrey-mp> hodepodge: +1
19:48:04 <catherineD> hogepodge: a boolean (soon to be a number) is specify a specific result
19:48:10 <andrey-mp> if we need 'mark as used for certification' then let's do it
19:49:10 <andrey-mp> it will be strange if this filed will store one number and result will be linked to another program...
19:49:29 <catherineD> look at this result https://refstack.openstack.org/#/results/91ae10c5-ecf5-4823-81d4-09836dc212cf
19:50:15 <catherineD> I associated that to a guideline and program and share it to everyone to see ... but that is not a record in hogepodge: 's cerfified list ..
19:51:04 <catherineD> we need some indication that the specific result is "used for certification"
19:51:19 <andrey-mp> yes! we need only boolean flag!
19:51:23 <catherineD> andrey-mp: you have a good point on inconsistency
19:51:57 <catherineD> and since we already have the program associated ... yep a bollean flag would work ...
19:52:51 <catherineD> rockyg: I think we go back to a boolean because we already have a way to associate program
19:53:21 <rockyg> ha ha ha.  Circles.
19:53:28 <catherineD> yup
19:53:46 <catherineD> andrey-mp: thx for bringing us back !  Power of team work !!!
19:53:54 <andrey-mp> :)
19:53:55 <catherineD> moving on?
19:54:30 <catherineD> I think there is no meeting after this meeting
19:54:42 <catherineD> we will go on until someone kick us out :-)
19:54:49 <catherineD> #topic Revisit cloudid  vs productid
19:55:20 <catherineD> #link please look at https://docs.google.com/presentation/d/1btnlXcCoucjbmUNd18QoPK68UNuNLN9oFvUBWtYgATo/edit#slide=id.gf21c0d478_11_0
19:55:36 <catherineD> let me explain ... I will signal when I am done
19:56:05 <catherineD> could you go to slide 6
19:56:42 <catherineD> what I am trying to explain is why we need an additional product_id column in the test table.... I will signal when I am done
19:57:30 <catherineD> in slide 6 ... the scenario is productA is a distro product  with a product_id in refstack
19:58:06 <catherineD> in order to test, the vendor of product A need to create a cloud with cloud_id_1 to test
19:58:20 <catherineD> this cloud was built in 2015 and the run test ..
19:58:51 <catherineD> so in this graph product to cloud to test are all link with cloud id
19:59:08 <catherineD> done for slide 6 description ... any question ?
19:59:15 <andrey-mp> i'm sorry - but let's start with main problem(concern) (because i don't understand what is discussed)
19:59:54 <catherineD> the main concern is using cloud_id to link test to product is not good for all cases ...
20:00:03 <andrey-mp> slide 6 - i'm not fully agree with phrase 'product_id is unique id among versions. next version is the next product
20:00:07 <catherineD> in slide 6 it is good
20:00:19 <catherineD> ok let me explain
20:00:22 <andrey-mp> like OpenStack Liberty, OpenStack Mitaka
20:00:35 <andrey-mp> here name is an ID
20:00:48 <andrey-mp> and these IDs are not unique
20:01:04 <andrey-mp> these IDs show us that something is changed
20:01:29 <andrey-mp> like major version in another distro's
20:01:42 <catherineD> let me explain  take any product in the marketplace (I just choose the first one come to the page) for example :  https://www.openstack.org/marketplace/distros/distribution/oracle/oracle-openstack-for-oracle-solaris
20:02:05 <catherineD> andrey-mp: are you with me on the marketplace product before I go on?
20:02:32 <andrey-mp> yeah
20:03:12 <andrey-mp> I see that this uses Juno version of OpenStack
20:03:34 <catherineD> so I go to refstack and create a product name "Oracle OpenStack for Oracle Solaris "  and that will create a product entry in the refstack product table with a unique prodcut_id
20:03:55 <catherineD> so at 2016 (today) it use Juno
20:04:47 <catherineD> in order to test the vendor (Oracle) in this case will build  a cloud based on this Juno product ... that clould will have cloud_id_1
20:04:48 <rockyg> guys, might want to move to refstack... past the hour...
20:05:03 <catherineD> rockyg: I notice that no meeting after us
20:05:13 <rockyg> Oh, then ok.
20:05:39 <catherineD> maybe we should move to #refstack?
20:05:52 <catherineD> we still have log there so we should be OK
20:06:05 <andrey-mp> for example - https://www.openstack.org/marketplace/distros/distribution/mirantis/mirantis-openstack
20:06:05 <andrey-mp> it has several versions - 6.1, 7, 8, 9
20:06:05 <andrey-mp> what version is certified and tested/
20:06:08 <andrey-mp> ?
20:06:09 <catherineD> #endmeeting