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