19:01:00 <catherineD|2> #startmeeting refstack
19:01:01 <openstack> Meeting started Tue Jul 26 19:01:00 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD|2. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:04 <openstack> The meeting name has been set to 'refstack'
19:01:14 <hogepodge> o/
19:01:57 <catherineD|2> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-07-26
19:01:59 <pvaneck> o/
19:02:51 <andrey-mp> o/
19:03:32 <rockyg> o/
19:03:35 <catherineD|2> #topic      DefCore midcycle next week
19:04:12 <catherineD|2> many of us will be at the DefCore midcycle next week ... do we still want to have RefStack IRC meeting next week?
19:04:27 <hogepodge> I won't make it
19:05:03 <catherineD|2> me neither
19:05:14 <catherineD|2> rockyg: yo uwill be at the midcycle right?
19:05:31 <rockyg> I'm trying to make it.  We'll see.
19:06:14 <rockyg> I've gotta get the travel approval trough today
19:06:24 <catherineD|2> so pvaneck: andrey-mp: how ablut you .. should we skip next week meeting?
19:06:27 <catherineD|2> rockyg: ic
19:06:44 <andrey-mp> sure )
19:06:47 <pvaneck> yea, might as well
19:07:03 <catherineD|2> ok
19:07:10 <catherineD|2> #topic     Mascot for RefStack ( https://etherpad.openstack.org/p/refstack-mascot )
19:07:25 <rockyg> Yeah.  Best time to get work done is when the managers are off meeting elsewhere
19:07:56 <catherineD|2> we have 3 options  ... thanks to hogepodge: and rockyg:  ...
19:08:45 <catherineD|2> I saw that one of the Keystone team's is bee ... so I think we should send in all 3 options just incase
19:08:56 <catherineD|2> if it is OK with everyone
19:09:33 <pvaneck> that is fine
19:09:50 <catherineD|2> alright moving on ...
19:09:57 <catherineD|2> #topic refstack-client spec for implementing additional properties DefCore waiver
19:10:03 <rockyg> I haven't had time to really put thought into it.
19:11:24 <catherineD|2> rockyg: I like the 3 options we have and  the deadline tomorrow .. I think it is good with what we have
19:11:54 <hogepodge> catherineD|2: can you add a beehive as another option to augment mine?
19:12:09 <andrey-mp> yesterday luzC and hogepodge discussed this feature on refstack channel and they will discuss this at Mid-Cycle
19:12:23 <catherineD|2> hogepodge: just beehive without bee?
19:12:32 <catherineD|2> bees?
19:13:09 <luzC> o/ hello sorry to be late
19:13:31 <hogepodge> catherineD|2: yeah, as an alternative since keystone will probably get priority
19:13:46 <pvaneck> keystone seems to have selected turtle as theirs
19:13:47 <catherineD|2> sure
19:14:25 <catherineD|2> please take a look at https://etherpad.openstack.org/p/refstack-mascot
19:16:22 <catherineD|2> back to the waiver spec ... yea luzC: hogepodge:  will discuss during midcycle ... the only question here is the spec is right now submit to refstack ... is it ok with everyone ?  I am ok with all spec in refstack (and not refstack-client)
19:18:01 <catherineD|2> moving on ..
19:18:10 <luzC> I'm ok with that...
19:18:15 <catherineD|2> #topic Specification for marking a record as "used for certification"
19:18:55 <pvaneck> might ultimately make more sense to just make a specs folder in the refstack-client repo. but i guess since we don't get make many specs for the client, in refstack is fine
19:19:30 <andrey-mp> pvaneck: +1, another folder is a good idea
19:19:39 <catherineD|2> andrey-mp: thanks for reviewing .... did you see my latest response?  I can remove the "action" option and make the API an Update API wiht PUT
19:20:14 <catherineD|2> andrey-mp: pvaneck: if you think adding a spec folder in refstack-client is a good idea .. then we should do it starting with this spec
19:21:58 <pvaneck> +1 to that
19:22:07 <catherineD|2> #action Create a spec folder in the refstack-client repository
19:22:14 <davidlenwell> o/
19:22:15 <andrey-mp> catherineD|2: yes, I saw your comment. but in any case there is another question - this spec should contain updated info about get/put methods for new column
19:22:45 <luzC> I'll create the new folder and and move the spec there...
19:22:56 <catherineD|2> luzC: thank you!!
19:23:26 <catherineD|2> andrey-mp: OK I will update the spec with get put with the new column
19:23:31 <rockyg> Hey David!  Long time no see!
19:23:40 <catherineD|2> davidlenwell: hi...
19:24:18 <catherineD|2> davidlenwell: it has been a long time ...
19:24:52 <davidlenwell> hi! I happened to be lurking in this channel and started reading the scroll back and descided not to be a fly on the wall for once
19:24:52 <catherineD|2> I will update https://review.openstack.org/#/c/343954/
19:25:21 <rockyg> davidlenwell, any ideas for mascot would be appreciated....
19:25:49 <davidlenwell> yeah .. I'll leave the etherpad open on my desktop and drop in my thoughts over the next couple of days
19:26:19 <rockyg> And, of course, design/implememntation thoughts
19:26:27 <catherineD|2> moving on to the next topic  ....
19:26:44 <catherineD|2> #topic Revisit using cloudid  vs productid to link test results to product
19:26:45 <davidlenwell> I had thought about that before when we first started out.. i wanted to code name the project something else because refstack had bad name association and to get better participation I wanted to rebrand.. but in the end im glad it is what it is
19:27:10 <davidlenwell> couldn't we use either or?
19:27:31 <davidlenwell> just have a feild for each and if one is blank refer to the other one?
19:28:32 <davidlenwell> http://66.media.tumblr.com/2694edccc3e66194057d9f54b2dec91c/tumblr_mnn50r2s4K1sosawio1_400.gif
19:28:41 <catherineD|2> hogepodge: question about product id .. in the example of 5.1.1 and 5.1.2     will that be one product or 2 products?
19:28:54 <catherineD|2> item 5.1.1 in https://etherpad.openstack.org/p/refstack-meeting-16-07-26
19:29:18 <hogepodge> That's one product with a different version
19:29:59 <andrey-mp> hogepodge: how it should be shown in the RefStack UI?
19:30:31 <hogepodge> Why not have a version field?
19:31:58 <andrey-mp> version field: is it a additional key field for product_id? (unique key is product_id + version)
19:32:38 <hogepodge> Sure. Make version optional too?
19:32:47 <catherineD|2> if unique key is product_id + version --> we might as well have a new product id ?
19:33:20 <andrey-mp> hogepodge: if version is included into a unique key then it can not be optional
19:33:22 <catherineD|2> hogepodge: if version is just information only , then unique key is still one column (product_id)
19:34:14 <andrey-mp> catherineD|2 but in this case only one item will be in DB - product_id with additional version field that is conatained all versions
19:35:08 <andrey-mp> and user will link something to whole product
19:35:09 <catherineD|2> andrey-mp: product_id is right now an UUID created by the system ... do you mean we will augment this field by adding version id?
19:35:17 <hogepodge> andrey-mp: empty is an option
19:35:37 <hogepodge> andrey-mp: and doesn't get in the way of uniqueness
19:36:05 <andrey-mp> hogepodge: is it mean that product does not have versions at all?
19:36:07 <catherineD|2> hogepodge: andrey-mp: seems like version is information only?
19:36:34 <hogepodge> a public cloud with continuous updates won't have a version associated with it, for example
19:37:40 <catherineD|2> hogepodge: +1
19:37:57 <andrey-mp> so, what about distros?
19:39:42 <andrey-mp> and btw - is it cloud based on Havana version is the same as based on Mitaka version? 'Havana' cloud can't pass most tests in the 2016 guideline...
19:40:26 <catherineD|2> andrey-mp: distro will have version but it would be information only and the version will be tag to the test results (optional) when associate to product
19:41:26 <andrey-mp> another situation - user can create two results and he wants to refer first result to Mirantis 6.1 and another result to Mirantis 9.0. Is it possible?
19:41:46 * tellesnobrega is away: I'm busy
19:42:23 <catherineD|2> andrey-mp: so mirantis will have a product id ... 6.1 and 9.0 can tag to the meta data of the test results
19:43:03 <andrey-mp> catherineD|2: this is very strange to store product version in the result...
19:43:05 <hogepodge> andrey-mp: yes to all of that? I don't see why not
19:44:54 <catherineD|2> andrey-mp: how would we store different versions in product table with the same product id  ?
19:45:34 <catherineD|2> anyway .. I suggest let's us give some thought on the example 5.1.1 and 5.1.2 ...
19:45:39 <andrey-mp> hogepodge: I think in terms of DB(or in terms of OOP) - result is an object(or one item in DB) and product(Mirantis OpenStack) is an another object. Where information about version should be stored?
19:47:10 <hogepodge> I don't feel strongly about it
19:47:28 <andrey-mp> catherineD|2: I see cases: 1. make different products for product with versions.(it's better) 2. Add version as column and use it in the uniquness(this has some minuses)
19:48:16 <catherineD|2> in 2 which table do you add the version column to?
19:48:24 <andrey-mp> product
19:48:24 <catherineD|2> test table or product table?
19:48:31 <rockyg> I kinda like 1 but we should get the pluses and minuses documented before we decide
19:48:32 <catherineD|2> that won't work
19:48:56 <andrey-mp> version is a part of product information
19:49:00 <andrey-mp> why???
19:49:10 <catherineD|2> how can a product row have more than one version?
19:49:33 <catherineD|2> so the mirantis row will have version as 6.1
19:49:40 <catherineD|2> where do you put 9.0?
19:50:02 <andrey-mp> catherineD|2: primary key must be composed from product_id and version
19:50:44 <catherineD|2> then pratically you option 2 is similar to 1
19:50:45 <andrey-mp> in this case table will allow to store two items with equal product_id and different version
19:51:20 <catherineD|2> andrey-mp: I think we make thing more complicated
19:51:37 <catherineD|2> I suggest we think about this and revisit next week
19:51:53 <andrey-mp> you can discuss it on mid-cycle
19:52:02 <catherineD|2> andrey-mp: we will ...
19:52:36 <andrey-mp> did you see Alex's comment about your slides in refstack channel?
19:52:47 <catherineD|2> let's discuss about cpid (cloudid) and product_id
19:52:54 <catherineD|2> andrey-mp: no
19:53:17 <andrey-mp> you asked to comment and he did it )
19:54:27 <andrey-mp> and I've added topic #8 into etherpad - as I remember you don't want to show OpenID to all
19:54:42 <catherineD|2> which date did he added comment?  I was out for 3 days last week ... I will check the channel
19:55:05 <andrey-mp> may be on 06/19
19:55:21 <andrey-mp> this is an example when I can find your OpenID )
19:55:23 <catherineD|2> ok sorry for missing that I will check the channel
19:55:37 <catherineD|2> back to cloudid vs productid
19:56:11 <catherineD|2> productid regardless whether it will include version of the product or not .. they are unique  ... cloudid is not
19:56:23 <andrey-mp> we have little time - maybe revisit this in two weeks?
19:56:38 <catherineD|2> or I should say cloudid by the way we define it by using hash of the keystone url
19:57:17 <andrey-mp> I thought that keystone public endpoint ID is used... it more unique
19:57:55 <catherineD|2> andrey-mp: you know that most  of the time we ended up not using keystone public endpoint ID ..right?
19:58:37 <andrey-mp> no, I don't know about it
19:58:40 <rockyg> Who can remember that far back into ancient history?-)
19:59:04 <andrey-mp> i see into the code )
19:59:27 <catherineD|2> andrey-mp: when you run refstack-client did you get a keystone endpoint id for your cloud?
19:59:47 <catherineD|2> or you actually getting the hash of the url?
20:00:20 <andrey-mp> catherineD|2: I don't know ) i didn't check what client passed to server
20:00:49 <andrey-mp> as I remember it was a endpoint ID in my installation
20:01:08 <andrey-mp> i need to go in 2-4 minutes
20:01:09 <catherineD|2> andrey-mp: please check and let me know
20:01:20 <catherineD|2> ok think about that subject ...
20:01:32 <catherineD|2> we will skip next week's meeting ...
20:01:35 <catherineD|2> thank you all
20:01:44 <catherineD|2> #endmeeting