19:00:01 <catherineD> #startmeeting refstack
19:00:02 <openstack> Meeting started Tue Jun 21 19:00:01 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:07 <openstack> The meeting name has been set to 'refstack'
19:00:43 <pvaneck> o/
19:00:43 <Rockyg> o/
19:01:05 <luzC> o/
19:01:20 <catherineD> hello everyone ..
19:01:23 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-06-21
19:02:05 <docaedo> o/
19:02:08 <sslypushenko> o/
19:02:33 <andrey-mp> o/
19:02:46 <catherineD> meeting agenda and notes, https://etherpad.openstack.org/p/refstack-meeting-16-06-21
19:03:01 <catherineD> #topic Product UI
19:03:35 <catherineD> #link     Add products UI base  ( https://review.openstack.org/#/c/329736/ )
19:04:24 <catherineD> andrey-mp: I feel like this is a good base for product UI ... of course there are many other features needed ...
19:05:00 <catherineD> if we think this is a good base , I suggest to merge it and make other enhancement later
19:05:08 <andrey-mp> catherineD: i think that product.html page should be divided to two pages - cloud and distro
19:05:37 <catherineD> andrey-mp: that is the detail page right?  when you click the product ?
19:05:46 <andrey-mp> yeah
19:06:11 <catherineD> I totally agree with you that at the detail page ...
19:06:23 <andrey-mp> so it should be in this review )
19:06:37 <catherineD> for example for cloud we need product_id defined but for distro we do not need to
19:06:45 <pvaneck> what would be the current difference between the two pages?
19:07:05 <Rockyg> question:  has anyone from the UX team toalked with us about our UI?
19:07:08 <andrey-mp> pvaneck: different properties, and different link maybe
19:07:42 <catherineD> Rockyg: that is a good idea ... do you have a name?
19:08:19 <catherineD> andrey-mp: exactly, and I think it take time to ion out ... so I would like us to  make it the next patch ..
19:08:59 <catherineD> My goal is to have an end-2-end UI demo to DefCore at the midcycle (week of Auguest 1st )
19:09:23 <andrey-mp> catherineD: strage way. first we create something and next we remove it. it's better to make two pages now
19:09:45 <catherineD> I would like us to make progress in the test result to product association and authorization
19:09:54 <andrey-mp> whay this refactoring is needed if we can do it normally?
19:10:06 <Rockyg> pieter kruithof is one of the guys.
19:10:22 <catherineD> andrey-mp: we do not remove something right?  the page now can  be used for distro we just add a page for cloud?
19:10:23 <Rockyg> There's another one, though, too.
19:11:00 <andrey-mp> catherineD: yes. but next patch will remove product.html and make cloud.html and distro.html. right?
19:11:05 <pvaneck> just different properties being shown? cant that be done with one page depending on the type
19:12:09 <andrey-mp> pvaneck: I think that is simplier to make two pages.
19:13:11 <catherineD> andrey-mp: I don't mind if we call the product.html .. distro.html for now and later add cloud.html .. do whatever is simple first and I think distro is simpler
19:13:22 <pvaneck> won't they essentially be duplicates right now?
19:13:29 <andrey-mp> maybe we will do different behavior for these pages - there is a link ability between cloud and distro in domain model https://docs.google.com/document/d/1s_dAIuluztlCC6AZ-WO4_FR2CLje1QyS6kbMxlFHaMk/edit#heading=h.8fxpb1onf6vr  for example
19:13:58 <andrey-mp> catherineD: we will not need product.html later. only cloud and distro
19:14:28 <catherineD> andrey-mp: so I don't mind if we rename the current product.html to distor.html
19:14:42 <andrey-mp> pvaneck: yes. right now it will be the same...
19:14:52 <pvaneck> if there are more cloud-specific stuff and distro-specific stuff later, could just call them as templates later from within product.html
19:15:06 <catherineD> essentially we are implementing everything as distro now (from UI point of view)
19:15:34 <andrey-mp> catherineD: ok. but what about cloud? what user will se if he clicks to cloud?
19:15:50 <catherineD> andrey-mp: for now it would be just like distro
19:16:30 <catherineD> until we implement cloud -specific stuff which is mostly needed for centralize testing
19:16:31 <andrey-mp> pvaneck: it's an idea. but I see future refactoring in this case
19:17:47 <catherineD> pvaneck: does it make sense to implement templates now ... the templates would be identical for now ... but it will avoid refactoring later
19:19:24 <pvaneck> I dont particularly mind. will go ahead and create the two cloud/distro html pages.
19:19:35 <pvaneck> im assuming the routes will be /cloud and /distro ?
19:19:50 <catherineD> pvaneck: great ..Thanks
19:20:01 <andrey-mp> pvaneck: I agree with names. thanks!
19:20:23 <pvaneck> okay will send a new patch later
19:21:04 <catherineD> #action pvaneck: will go ahead and create the two cloud/distro html pages  for  https://review.openstack.org/#/c/329736/
19:21:14 <catherineD> andrey-mp: pvaneck:  Thank you!
19:21:33 <catherineD> #topic Product table
19:22:17 <catherineD> right now in the product table .. we have an id and product_id fields which are very confusing
19:22:50 <catherineD> to me the product_id field is actually the cloud_id  ... or cloud provider ID ...
19:22:59 <andrey-mp> we discussed it several months ago
19:23:18 <andrey-mp> and agreed that it is a product_id
19:23:40 <andrey-mp> so I disagree to rename it now
19:24:02 <catherineD> andrey-mp: I know we did but it becomes increasingly annoying
19:24:21 <andrey-mp> because cloud and distro are both products
19:24:46 <catherineD> so when we refer to the id filed in the product table we would say product id ... but we do not mean product_id
19:25:27 <Rockyg> so, is it a type, or is it a specific one off ID?
19:25:31 <andrey-mp> we created product_id to be able to provide it externally
19:25:57 <catherineD> I agree that cloud and distro a both product ... the way I see is a product can be instantiated to one cloud or many clouds
19:26:34 <andrey-mp> I will create a patch for refstack-client to provide cpid as product_id (i hope this week)
19:27:06 <catherineD> andrey-mp: I don't agree to change cpid to product id
19:27:35 <andrey-mp> we talked about it last day of Austin's summit?
19:27:38 <catherineD> for refstack-client definitely it has to be a cloud ... because that is what being tested
19:27:55 <andrey-mp> but what cloud is in refstack?
19:28:32 <catherineD> a cloud in RefStack is an instant of a product
19:28:55 <catherineD> something it is 1-1 relationship like public cloud
19:29:12 <catherineD> something --> sometime
19:29:34 <catherineD> on other time product ot clouds may have 1 to n relationship
19:29:35 <sslypushenko> catherineD: +1
19:29:58 <sslypushenko> product can be presented as many clouds
19:30:34 <catherineD> so when testing we must test a  specific cloud intantiated based on a product
19:30:46 <sslypushenko> if I remember right, all of us agreed with his statment
19:31:22 <sslypushenko> *his -> this
19:31:31 <andrey-mp> ok. and we agreed that refstack-client tests cloud. and passes cloud_id (as cpid) to refstack
19:31:32 <catherineD> that is why I would like to rename the product_id field in the product table to cloud_id
19:31:53 <andrey-mp> and what it will mean for distro?
19:33:24 <sslypushenko> good question...
19:33:36 <catherineD> a distro is a product that someone must instantiate a cloud before we can test .. and this cloud can be temperary and so is the cpid (which can be changed  on each installation of the cloud)
19:34:21 <catherineD> temepary - temporary
19:34:46 <catherineD> the reason I want to rename the product_id field is because we are still early in this implementation ..
19:34:51 <andrey-mp> what will mean cloud_id in product table for distro?
19:36:02 <sslypushenko> it should be something like uuid
19:36:11 <catherineD> cloud_id in the distro is just a place holder ... cloud_id is only important for public cloud or centralize testing .. where cloud_id is used as the access URL to the cloud
19:36:34 <sslypushenko> but we need a way how to link distro with instance of cloud
19:36:39 <catherineD> right now cloud_id can even be null for distro
19:37:02 <catherineD> sslypushenko: that is topic #3 for today
19:37:13 <Rockyg> houw about cloud_instance_id?
19:37:23 <sslypushenko> too complecated
19:37:27 <catherineD> Rockyg: I don't mind that
19:38:10 <catherineD> how about we go on to discuss topic #3 then revisit this topic?
19:38:13 <Rockyg> more specific, so harder to confuse
19:38:22 <catherineD> Rockyg: ++
19:38:35 <sslypushenko> lets assume that it is just autogenerated uuid
19:39:06 <sslypushenko> catherineD: move on to #3
19:39:39 <andrey-mp> please stop on #2
19:39:45 <catherineD> sslypushenko: in the product table .. the id field is auto generated  and guarantee to be unique .. the product_id field is not
19:39:49 <catherineD> ok
19:39:53 <andrey-mp> Alex come to us
19:40:16 <catherineD> we will revisit #2 later ... moving on to #3?
19:40:24 <sslypushenko> +
19:40:32 <catherineD> #topic Associating test results data to a product
19:40:49 <catherineD> #link     Specification to associate test results to products. (  https://review.openstack.org/#/c/332260/ )
19:40:54 <alevine_> Hi everybody :)
19:41:07 <catherineD> alevine_:hello ... How are you?
19:41:22 <sslypushenko> alevine_:  Привет!)
19:41:23 <alevine_> Great, thanks. Hope everybody's great as well
19:41:47 <catherineD> so I guess we want to go back to topic #2 ? since alevine_:  joins us?
19:42:29 <sslypushenko> lets go to #3
19:42:32 <alevine_> Andrey asked me to attend, so if possible it'd be great to reiterate.
19:42:34 <catherineD> ok
19:43:01 <catherineD> so  the suggestion is to add 2 more fields to the test table
19:43:27 <catherineD> a product_uuid field and a certification field ...
19:43:36 <catherineD> in the test table
19:43:39 <andrey-mp> catherineD: this is related to #3 but I called Alex for #2 )
19:44:19 <catherineD> sslypushenko: sorry since alevine_: is here let's go back to #2 .. hope you are OK with that
19:44:19 <sslypushenko> ok, 2 or 3 - I don't mind
19:44:26 <catherineD> sslypushenko: thx :-)
19:45:28 <catherineD> alevine_: so my suggestion is to change the name of the product_id field in the product table to cloud_id  ( Rockyg: suggests  cloud_instance_id)
19:45:49 <alevine_> Why?
19:46:07 <alevine_> And have we decided that our products are clouds only, no more distros?
19:46:58 <sslypushenko> alevine_: hmm
19:47:03 <catherineD> because right now every time we refer to the id field in the product table we will say product id and that maybe misunderstand as the product_id field
19:47:04 <Rockyg> So, the tests are done on a cloud instance, but the instance can either be a cloud product or a distro product.
19:47:17 <catherineD> Rockyg: correct
19:47:50 <sslypushenko> Rockyg:  not exactly
19:48:02 <catherineD> and for a distro product it may have more than one cloud instances
19:48:03 <alevine_> Or it can be some other software of non-distro kind eventually we're testing it for, like ec2
19:48:29 <andrey-mp> Rockyg: we can't test a distro itself - only cloud with installed Distro
19:48:38 <sslypushenko> But, I guess we need some kind of aggregation, like distro
19:49:05 <Rockyg> alevine_, wouldn't the tests still run on a cloud?  but the "product" would be ec2 compatibility?
19:49:13 <alevine_> I mean why are we even getting back to this? I thought we're done with the products design and it's ok? We can't just use term cloud in the product table for products - we'd have to get rid of everything non-cloud and rename the product table to cloud table.
19:49:18 <sslypushenko> andrey-mp:  exactly, but still we have a distro like point of aggregation
19:49:37 <alevine_> rockyg: Have you had a chance to read my doc?
19:49:49 <Rockyg> It's been a long while....
19:49:50 <alevine_> I mean the design one
19:50:01 <andrey-mp> sslypushenko: sure, we can see it on diagram of domain model - https://docs.google.com/document/d/1s_dAIuluztlCC6AZ-WO4_FR2CLje1QyS6kbMxlFHaMk/edit#heading=h.8fxpb1onf6vr
19:50:04 <Rockyg> I need to go back to it.
19:50:12 <alevine_> Well, I hope it answers this kind of questions.
19:50:41 <Rockyg> Thanks for the link
19:50:54 <alevine_> And even without it - we can't start mixing entities. Product table means product id. We just can't start renaming something inside of it without changing its own semantics... and hence revisiting the whole design.
19:50:59 <catherineD> alevine_: the reason we need to go back to this is we have a hard time to differentiate the id field in the product table vs the product_id field itself
19:51:38 <catherineD> alevine_: there is an id fiield in the product table .. and there is a product_id field also
19:51:46 <andrey-mp> catherineD: id - is an internal UUID. product_id - external identifier
19:51:53 <alevine_> Well, one is GUID - another one is some external ID. That's all differentiation there is
19:52:00 <catherineD> alevine_: I know
19:52:26 <alevine_> Let's name one PRODUCT_GUID and second PRODUCT_EXTERNAL_ID if it'll make it clearer
19:52:36 <catherineD> sorry that is for andrey-mp:  I know that id is internal UUID and I trust that this ID is unique
19:52:46 <Rockyg> that would help, I think
19:53:03 <alevine_> sure. I'm totally pro this
19:53:17 <Rockyg> Need a longer name to clarify and interenal vs external is an important differentiator
19:53:29 <sslypushenko> still sounds bad...
19:53:40 <catherineD> alevine_: I don;t kine .. let's keep id as id to be consistent to the other table /..
19:53:42 <alevine_> If something is ambiguous it definitely should be renamed but without change of semantics
19:54:02 <catherineD> I don't mind rename product_id to product_external_id
19:54:07 <Rockyg> alevine_, ++
19:54:11 <alevine_> ID and External_ID then?
19:54:36 <catherineD> alevine_: I like that
19:54:39 <catherineD> better
19:54:48 <catherineD> sslypushenko: how about you?
19:54:49 <alevine_> ++
19:55:07 <sslypushenko> I'd rather see  _id for internal id and just product_id for external one
19:55:33 <andrey-mp> sslypushenko: why?)
19:55:49 <alevine_> I'm personally fine with ID and PRODUCT_ID at it is because ID can be autoincrement or GUID in our case and PRODUCT_ID is definitely something from the outside world and more substantial
19:56:01 <sslypushenko> because actually product_external_id is not really external) If I'm understand things correctly
19:56:06 <catherineD> sslypushenko: but when you talk about it you would say id of the product table and not underscore id of the product table right?  so it is still confusing
19:56:18 <alevine_> I agree with sslypushenko
19:56:37 <catherineD> sslypushenko: it could be external because  it is user defined
19:56:53 <sslypushenko> user just selects it
19:57:20 <sslypushenko> you can not specify not existed id in this field
19:57:24 <catherineD> sslypushenko: say to go a public cloud ... this would be the URL of the public cloud right?
19:57:40 <sslypushenko> just make selection from existed disto's ids
19:57:42 <alevine_> Rename ID to GUID and everything will be clear :)
19:58:05 <catherineD> alevine_: that is not how the other table are defined
19:58:06 <andrey-mp> catherineD: from the document - CloudID ideally should be single, unique and automatically determined for each Cloud. For OpenStack Cloud it should be determined as a hashed Public ID of keystone endpoint, including keystone ID.
19:58:14 <catherineD> I would like the talbe to be cosistent
19:58:18 <alevine_> Let's rename it everywhere if it's actually GUID
19:58:48 <catherineD> alevine_: I don't think so
19:59:09 <alevine_> I mean it's a very common situation to have two IDs in DB table. One is the auto-ID given by the DB and another one is real-life ID.
19:59:09 <sslypushenko> _id look a bit convinient
19:59:11 <catherineD> we are running out of time ... and I have a meeting to go next
19:59:28 <alevine_> Usually it is not the case to use "external" or something for such a real-life id.
19:59:29 <sslypushenko> lets move to #refstack for extra 10 mins
19:59:41 <sslypushenko> we ran out of time)
19:59:49 <catherineD> everyone ...could you review https://review.openstack.org/#/c/332260/
20:00:00 <catherineD> thank you everyone
20:00:05 <catherineD> #endmeeting