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