19:00:53 <catherineD> #startmeeting refstack 19:00:54 <openstack> Meeting started Mon Sep 14 19:00:53 2015 UTC and is due to finish in 60 minutes. The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:58 <openstack> The meeting name has been set to 'refstack' 19:01:16 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-15-09-14 19:02:08 <pvaneck> o/ 19:02:13 <catherineD> roll call 19:02:31 <sslypushenko__> o/ Hi, all! 19:02:47 * markvoelker lurks 19:02:51 <pvaneck> hi sslypushenko__ 19:03:12 <catherineD> hell pvaneck: sslypushenko__: 19:03:17 <catherineD> hello 19:03:20 <catherineD> :-) 19:03:20 <pvaneck> hah 19:04:09 <catherineD> do you get the link to the agenda? 19:04:40 <catherineD> #topic Relocate RefStack Project 19:05:33 <catherineD> #info RefStack repositories moved to openstack namespace on 20150911 19:06:07 <pvaneck> I think just about all the references were updated to reflect this change 19:06:24 <pvaneck> pending +A for a refstack-client patch 19:07:16 <catherineD> sslypushenko__: could you review the refstack-client patch please 19:07:24 <sslypushenko__> Sure 19:08:11 <sslypushenko__> Done) 19:08:55 <catherineD> congrats to ourself for being part of the OpenStack "Big Tent" 19:09:00 <catherineD> sslypushenko__: thx 19:09:24 <sslypushenko__> catherineD Big move for RefStack) 19:09:52 <catherineD> Yes it is ... it has been a long journey .. thank you all! 19:10:01 <catherineD> #topic Infra hosting 19:10:16 <catherineD> pvaneck: any update? 19:10:45 <pvaneck> just have to add proper https parameters to the system-config patch, then i think we should be good 19:11:31 <catherineD> that is good .... who is doing that? 19:11:36 <pvaneck> #link https://review.openstack.org/#/c/198869/ 19:13:35 <pvaneck> I will have to see how the hiera params are set for all the ssl certs and stuff 19:13:51 <pvaneck> need to make sure they match the expected params in puppet-refstack 19:13:51 <catherineD> pvaneck: thx ... 19:14:13 <catherineD> let move to the next big topic ... 19:14:20 <catherineD> #topic CPID 19:15:04 <catherineD> #link https://review.openstack.org/#/c/221555/ 19:15:31 <catherineD> #link original UUID spec https://review.openstack.org/#/c/99500/ 19:16:27 <catherineD> I would like have an update to this spec to spell out the following: 19:16:47 <sslypushenko__> #link https://review.openstack.org/#/c/222582/ This patch removes dependency on admin creds, is it not enough? 19:17:04 <catherineD> 1) update to use service catalog with non-admin user 19:17:21 <catherineD> 2) update to also support keystone V3 API 19:18:10 <catherineD> sslypushenko__: we should take this opportunity to discuss about Keystone V3 support 19:18:21 <sslypushenko__> https://review.openstack.org/#/c/222582/ can be considered as quick fix 19:18:38 <sslypushenko__> I can easily add v3 support here 19:18:53 <catherineD> sslypushenko__: please do 19:19:03 <sslypushenko__> Main issue there is not V3 support 19:19:13 <catherineD> sslypushenko__: yes 19:19:21 <sslypushenko__> We shouldn't use creds from tempest.conf 19:19:38 <sslypushenko__> it will be depreciated soon 19:20:18 <catherineD> The other issue as point out by pvaneck: 's comments is that the ID field returned by V2 and V3 are different "things" if using the catalog command... 19:20:57 <sslypushenko__> hmm... in my devstack setup they are equal 19:21:06 <catherineD> for v2 and v3? 19:21:11 <sslypushenko__> yes 19:21:47 <catherineD> we check the keystone code ... it does not look so from the code ... 19:22:07 <sslypushenko__> hmmm... I can try again 19:22:16 <catherineD> the v3 id returned by the catalog commend is the keystone service ID ... 19:22:20 <pvaneck> for me, only v3 gave the identity service_id, and v2 gave the id in the database associated with internalURL of identity 19:23:00 <edmondsw> this might help understand the differences in ids between v2 and v3 https://review.openstack.org/#/c/164826/ 19:23:14 <catherineD> where in V2 the ID is the endpoint ID that return at index one of the dictionary ... 19:23:17 <hogepodge> o/ 19:23:35 <edmondsw> in short, there is an id field in v2 that does map directly to an id field in v3 19:24:09 <stevemar> edmondsw: ++ 19:25:00 <catherineD> edmondsw: we will take a look at the patch ... 19:26:09 <catherineD> currently our issue is the ID being returned in V2 could be one of the 3 IDs of admin, public, private endpoint ... but it is not guarantee which one being use ... 19:26:56 <hogepodge> Is it repeatable? 19:27:19 <hogepodge> That is, does it matter as long as the same call is made? 19:28:18 <catherineD> we will update RefStack spec such that .... RefStack will always use the ID from the V3 if the V3 API is supported (that is for env only supports V3 or one that supports both v2 and v3) 19:28:42 <catherineD> hogepodge: repeatable or not is depending on the underline database ... 19:29:01 <catherineD> we can not control that behavior ... 19:29:07 <sslypushenko__> In my setup V2 ID are equal to public V3 ID 19:29:19 <sslypushenko__> I have just checked 19:29:31 <catherineD> sslypushenko__: and v3 id is the service id? 19:29:51 <sslypushenko__> service id is different 19:30:11 <sslypushenko__> but id for public endpoint is eqaul 19:30:21 <catherineD> I mean what is the id field if you use v3 API to get the catalog 19:31:18 <sslypushenko__> This issue needs additional investigation 19:31:29 <catherineD> sslypushenko__: agree 19:31:45 <sslypushenko__> Maybe it is just coincidence... 19:32:06 <catherineD> that is why we need a spec to spell out exactly how RefStack will implement to handle V2 and V3 19:32:07 <sslypushenko__> But anyway almost all clouds support V2 for now 19:32:30 <sslypushenko__> For our biggest trouble not a v3 support 19:33:00 <catherineD> sslypushenko__: please look at the refstack IRC .... we just encounter a cloud which only support V3 API ... 19:33:22 <sslypushenko__> Oh... interesting) 19:33:42 <catherineD> sslypushenko__: we also just have a bug opened https://bugs.launchpad.net/refstack/+bug/1495671 19:33:43 <openstack> Launchpad bug 1495671 in refstack "not supporting V3 when fetching the Keystone ID being used as Cloud Provider ID" [Undecided,New] 19:35:03 <pvaneck> <sslypushenko__: you were saying that tempest.conf user creds were being deprecated 19:35:04 <sslypushenko__> I will look what I can do 19:35:17 <pvaneck> is that in favor of accounts.yaml credentials? 19:35:17 <sslypushenko__> pvaneck Yeap 19:35:35 <catherineD> #agreed RefStack team to investigate and create/update a spec to cleary describe how RefStack obtains CPID with V2/V3 Keystone API 19:35:50 <sslypushenko__> Actually, both ways should work 19:36:11 <sslypushenko__> So, we need to use tempest for extracting creds 19:36:49 <catherineD> CPID should be our priority for this week....since we have a case where the user can not run test ... 19:37:09 <pvaneck> sure, i'll play around with it as well 19:37:57 <catherineD> anything else? 19:38:27 <catherineD> moving on ... 19:39:10 <catherineD> #topic ReStack mailling list 19:39:53 <catherineD> at some point , I heard from rocky: that we should not use fits@OpenStack.org 19:40:12 <catherineD> but she is not here today ... 19:40:49 <pvaneck> just use openstack-dev with [RefStack] in topic if ever we have to send out something I suppose 19:41:21 <sslypushenko__> pvaneck +1 19:41:22 <catherineD> hogepodge: sslypushenko__: what do you think of pvaneck: 's suggestion? 19:42:48 * markvoelker thinks that'a a fine way to go and would fit in with how a lot of other Big Tent projects work 19:44:17 <pvaneck> yea, we are /openstack now so seems right 19:44:43 <catherineD> #agreed Use openstack-dev with [RefStack] in the topic for RefStack related mails. Stop using fits@OpenStack.org . 19:45:07 <catherineD> #topic Can RSA key be shared among users? 19:45:21 <catherineD> #link https://bugs.launchpad.net/refstack/+bug/1494679 19:45:22 <openstack> Launchpad bug 1494679 in refstack "When user upload the same ssh keys twice, refstack will response internal error" [Undecided,New] 19:45:53 <pvaneck> that was already addressed as david confirmed in the comments 19:46:16 <pvaneck> but i don't think two users can have the same key with the current implementation 19:47:19 <sslypushenko__> Absolutely 19:47:23 <catherineD> should we allow 2 users with the same key? 19:47:39 <sslypushenko__> For what reason? 19:47:53 <catherineD> think about the case of one vendor with multiple users// 19:47:57 <markvoelker> I'll chime in here since I owe you a spec on vendor registration which has somewhat similar concenrs 19:48:10 <catherineD> markvoelker: yes ...thx 19:48:41 <markvoelker> I'm generally of the opinion that key sharing is a Bad Thing that we should avoid. Rather, keys are linked to individuals and some other process links individuals to organizations 19:49:01 <markvoelker> So IMHO the current behavior is fine in that respect. 19:49:34 <sslypushenko__> vendor registration will be done in some other way than key sharing) 19:50:00 <catherineD> but right now the data only link to key and nothing else .. 19:50:32 <catherineD> so for someway if we keep what we are implemented today we need to link key to vendor 19:50:45 <catherineD> because user can move from vendor to vendor ... 19:51:21 <markvoelker> catherineD: I think there are mechanisms to accomplish that relatively easily. Have we consulted with the Foundation as to how they've handled this in the past? 19:51:44 <sslypushenko__> catherineD We need link test result to vendor , not key 19:52:21 <catherineD> markvoelker: I was hoping for some response to my mail from the Foundation ... 19:52:29 <markvoelker> Because, IMHO, you could do something along the lines of have the result tied to a key, have the user send in his email requesting logo status to the Foundation via email from a company address signed with that same key, etc. 19:53:19 <markvoelker> SOmething along those lines could verify that the submitter works for the vendor in question (assuming they don't give corporate email to just anyone), though there are other issues... 19:53:31 <markvoelker> ...e.g. making sure they're authorized by the company to speak for the product in question. 19:54:20 <markvoelker> (there are over 80k employees at my last company, of whom maybe 3 would be authorized to do official things for an OpenStack product =p) 19:54:45 <catherineD> markvoelker: yup ... would you response to the email ... hopefully the Foundation will give feedback too .. 19:55:10 <sslypushenko__> In RefStack key identifies user and nothing more... Relations between vendors and user it is something completely else) 19:55:27 <markvoelker> catherineD: Yes, I'm drafting something up 19:55:38 <catherineD> markvoelker: thank you so much ... 19:56:08 <catherineD> 5 mins left let discuss the next topic quickly ... which is somewhat related ... 19:56:33 <catherineD> #topic Disable anonymous data upload now that user can decide to share data anonymously. 19:57:23 <catherineD> I guess this will be our target .. 19:57:29 <catherineD> do we have agreement here? 19:57:47 <hogepodge> uhm, I don't like the extra step of creating an account 19:57:51 <hogepodge> etc etc 19:58:07 <hogepodge> I think it will reduce participation (which we already have a hard time encouraging) 19:58:12 <catherineD> with anonymous upload ... we can never able to clean up the data 19:58:14 <hogepodge> that's just my $0.02 though 19:58:31 <catherineD> hogepodge: very valid concern about partipation .... 19:58:42 <catherineD> hogepodge: that is what bothering me too... 19:58:43 <hogepodge> yeah, bad results is a problem 19:59:17 <catherineD> hogepodge: with signed data upload now user can do clean up by deleting data 19:59:37 <sslypushenko__> Lets move disscussion to refstack channel 19:59:41 <catherineD> with anonymous data we can not delete . .. 19:59:43 <catherineD> ok 19:59:58 <catherineD> #endmeeting