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