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