19:00:31 <catherine_d|1> #startmeeting refstack 19:00:32 <openstack> Meeting started Mon Dec 21 19:00:31 2015 UTC and is due to finish in 60 minutes. The chair is catherine_d|1. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:35 <openstack> The meeting name has been set to 'refstack' 19:03:09 <pvaneck> o/ 19:04:01 <catherine_d|1> pvaneck: hello 19:04:20 <sslypushenko> o/ Hi, all! 19:04:55 <pvaneck> hello! 19:05:40 <alevine> o/ 19:06:07 <catherine_d|1> sslypushenko: Hi ... most of the poeple in the US are taking off starting this week? Is it the same in yoru areas? 19:06:18 <catherine_d|1> hi alevine: 19:06:25 <catherine_d|1> so we of most of us here .. 19:06:35 <catherine_d|1> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-12-21 19:07:07 <sslypushenko> catherine_d|1: Nope 19:07:29 <catherine_d|1> #topic Confirm on data model 19:07:45 <catherine_d|1> do we still need sometime to think about this? 19:08:24 <catherine_d|1> sslypushenko: ic 19:08:27 <sslypushenko> I think we got basic agreement on this 19:08:27 <alevine> catherine_d: Didn't we agree to start with the object model? 19:09:04 <sslypushenko> We can put object model in spec and discuss it on review 19:09:24 <sslypushenko> It will be much more effective 19:12:07 <catherine_d|1> #agreed Catherine start submitting spec including object model for formal discussion 19:12:17 <sslypushenko> great! 19:12:52 <catherine_d|1> that make it easy ... 19:13:23 <catherine_d|1> #topic Do we need a meeting on 2015-12-28? 19:14:32 <sslypushenko> It will work for me, if needed 19:14:53 <catherine_d|1> alevine: pvaneck: how about you? 19:15:05 <pvaneck> likely wont be around 19:15:09 <alevine> catherine_d: I don't know. I can attend if required 19:15:54 <catherine_d|1> alevine: are you on vacation? 19:16:20 <alevine> catherine_d: Nope. I'll be on vacation 1-10 in January. But maybe I'll be able to attend then as well. 19:16:46 <catherine_d|1> ic then Let's have a meeting on Dec 28 and skip the meeting on Jan 4 19:17:26 <catherine_d|1> pvaneck: I know you are on vacation next week not a pressure for you to attend 19:17:57 <catherine_d|1> sounds good for everyone ... meeting on Dec 28 and skip Jan 4? 19:18:05 <sslypushenko> +1 19:18:07 <pvaneck> that's fine 19:18:35 <alevine> ok 19:18:39 <catherine_d|1> #agreed RefStack will have meeting on December 28. 19:18:54 <pvaneck> in any case, a lot of discussion can be done on the spec review comments. 19:19:00 <pvaneck> still getting used to the new gerrit 19:19:13 <catherine_d|1> pvaneck: ++ 19:19:21 <sslypushenko> pvaneck: +100500) 19:19:34 <catherine_d|1> #agreed No RefStack meeting on Jan 4, 2016 !!! 19:19:41 <catherine_d|1> 2016 already :-) 19:19:57 <catherine_d|1> #topic Open discussions 19:20:52 <catherine_d|1> sslypushenko: Please review https://review.openstack.org/#/c/259221/ and https://review.openstack.org/#/c/258178/ 19:21:13 <sslypushenko> Will do 19:21:48 <catherine_d|1> sslypushenko: thx 19:22:45 <catherine_d|1> so seems like in Russia and Ukraine... people taking vacation on the New Year rather than Christmas? 19:23:14 <sslypushenko> catherine_d|1: Yeap 19:23:18 <alevine> catherine_d: In Russia we have official state holidays 1-10 January 19:23:39 <sslypushenko> We have Christmas at 7Jan 19:24:15 <catherine_d|1> alevine: ic ... In the US most people will start on Jan 4 .. but I will start on Jan 7 :-) 19:24:21 <catherine_d|1> anything else? 19:24:35 <sslypushenko> https://review.openstack.org/#/c/259221/ looks good, after it we need one more thing 19:24:36 <catherine_d|1> anything else to discuss? 19:24:42 <sslypushenko> for refstack-client 19:25:19 <sslypushenko> we should get rid of keystone-client dependency 19:25:24 <catherine_d|1> sslypushenko: what does it need? pvaneck: is here... 19:25:34 <sslypushenko> And use tempest approach 19:25:49 <sslypushenko> Just do raw api call 19:25:58 <catherine_d|1> sslypushenko: agree. Although I think that should be a different patch ... 19:26:00 <sslypushenko> and parse the personce 19:26:10 <sslypushenko> yeap, sure 19:26:20 <sslypushenko> just a next step 19:26:29 <catherine_d|1> sslypushenko: could you log a bug on that ? 19:26:47 <sslypushenko> sure 19:27:12 <catherine_d|1> sslypushenko: great thx! 19:27:22 <pvaneck> Yea, I could try that out 19:27:34 <sslypushenko> It should be easy 19:27:46 <sslypushenko> currently we almost do this thing 19:28:09 <sslypushenko> ok, will create a bug of it 19:28:33 <catherine_d|1> we can also get rid of the code to get the credential from the tempest.config file because it wil lbe removed in Mitaka ... credential should be from the accoutns file 19:28:57 <sslypushenko> lets keep it for a while... 19:29:06 <sslypushenko> migrations is not going so fast 19:29:32 <catherine_d|1> sslypushenko: ok 19:29:50 <catherine_d|1> so https://review.openstack.org/#/c/259221/ should be good to merged? 19:30:26 <sslypushenko> yeap, just want to discuss one more related thing 19:30:41 <catherine_d|1> sslypushenko: yep absolutely . 19:31:12 <sslypushenko> maybe, it will make sense to keep both ids? 19:31:24 <sslypushenko> keystone ID and url hash? 19:31:45 <sslypushenko> What do you think? 19:32:47 <sslypushenko> My thought is: both IDs don't fits perfectly as a product ID 19:32:47 <catherine_d|1> sslypushenko: we can discuss about that but I think it would not be necessay once we have the other models (like product or provider ) created ... 19:33:18 <sslypushenko> yeap 19:33:41 <sslypushenko> product ID and vendor ID make sence 19:34:01 <catherine_d|1> sslypushenko: Let revisit this once we decided o nthe data model 19:34:32 <sslypushenko> we deferentially do 19:34:54 <sslypushenko> but maybe anyone have related thought just now 19:35:01 <sslypushenko> but maybe anyone have related thoughts just now 19:35:18 <catherine_d|1> I would like https://review.openstack.org/#/c/259221/ merged so that we can offer upload of submit data format ... 19:36:06 <catherine_d|1> alevine: pvaneck: your thoughts on keeping both Keystone and URL for CPID? 19:37:40 <pvaneck> hmm, well i suppose it would help with the cases where clouds were tested and cpids were retrieved differently 19:38:15 <pvaneck> how would we store this additional uuid 19:38:30 <sslypushenko> In metadata, I think 19:38:35 <alevine> catherine_d: I think as for the format - string is ok for anything. Otherwise we can assess which clouds we'll be dealing with (I see OpenStack, Amazon, Google, Azure, and others like Eucalyptus...) and figure what can serve as a cloudID for them. More important I guess is if we can always automatically determine it. 19:40:03 <catherine_d|1> alevine: If the CPID was created by hasi=hing the cloud URL .. we can always automatically determine it ... 19:40:06 <alevine> catherine_d: Again, just to make it clear. I think we're talking about cloudID and it's possible content, right? Or I'm confusing the meaning of cpid again? 19:40:42 <alevine> catherine_d: Which URL? Taken from where? Different tests would have different endpoints and URLs in the same config 19:40:46 <catherine_d|1> alevine: yup in this sense cloudeID is CPID 19:41:12 <catherine_d|1> in tempest config you only on one url for v2 and one for v3 19:42:07 <catherine_d|1> we will use which ever url the cloud tell us to use (by tempest config) as the base url 19:42:07 <alevine> catherine_d: v2 and v3 keystone I presume. But this is only for OpenStack clouds. We were talking about possibility to test non-OpenStack clouds as well. They do not have keystone. EC2 has different urls 19:42:47 <alevine> catherine_d: Who defines what url "cloud tells us to use" and when? 19:43:03 <sslypushenko> alevine: 19:43:07 <catherine_d|1> alevine: understand that those non-openstack cloud would have no keystone ... that is why we create cpid base on url 19:43:31 <sslypushenko> alevine: Anyway it should be something like endpoint to auth service 19:43:36 <catherine_d|1> alevine: they must have one url ... 19:43:41 <sslypushenko> in any kind of clouds 19:43:48 <catherine_d|1> sslypushenko: +1 19:44:30 <sslypushenko> so lets assume that we will get a hash from auth endpoint 19:45:10 <alevine> catherine_d: They do, yes. It is stored in config, yes. Should we teach RefStack to look for EC2_API_endpoint = url in the config? And can we trust it? I mean there is still lots to think of. That's why I guess string is fine for anything. 19:45:40 <alevine> catherine_d: Hash is also ok. 19:46:38 <sslypushenko> alevine: It will be hash to not keep vulnerable user info on server side 19:46:53 <catherine_d|1> alevine: yup that is what https://review.openstack.org/#/c/259221/ does as a last resort that RefStack will always able to create a CPID 19:47:28 <alevine> yes, hash is perfect 19:50:08 <sslypushenko> catherine_d|1 As a result of out discussion, I start thinking that the best solution for now will be use url hash as CPID and store keystone id in test metadata 19:50:30 <sslypushenko> thoughts? 19:52:11 <catherine_d|1> I am ok with that could we take that as the next step? we should just merge https://review.openstack.org/#/c/259221/ for now? 19:52:41 <sslypushenko> I will put my opinion in review, ok? 19:52:48 <catherine_d|1> sslypushenko: sure 19:52:58 <sslypushenko> great 19:53:04 <catherine_d|1> and also about not using keystone client 19:53:15 <sslypushenko> yeap 19:53:25 <catherine_d|1> sslypushenko: great .. 19:54:02 <catherine_d|1> anything else? 19:54:15 <sslypushenko> nothing from my side 19:54:39 <catherine_d|1> about https://review.openstack.org/#/c/256279/ 19:55:09 <catherine_d|1> originally we prefer to use V3 Keystone ID becayse it is a true Keystone service ID 19:55:31 <catherine_d|1> this patch suggest that we use whichever define by auth ... 19:55:58 <catherine_d|1> sslypushenko: pvaneck: do we still want to keep the V3 as preference? 19:56:18 <sslypushenko> We should stick to our solution 19:56:41 <sslypushenko> V3 is preferable 19:57:00 <catherine_d|1> pvaneck: how about you? 19:57:04 <pvaneck_> +1 19:57:09 <catherine_d|1> sslypushenko: that is my position too 19:57:47 <catherine_d|1> #agreed To keep using V3 Keystone ID as the prefer ID for CPID 19:58:25 <catherine_d|1> I think that is all for today ... thank you all.... Happy Holidays ... talked to you on December 28 19:59:13 <sslypushenko> Thx to all! 19:59:32 <catherine_d|1> #endmeeting