Monday, 2016-08-22

*** dave-mccowan has joined #openstack-barbican01:02
*** dave-mccowan has quit IRC01:02
*** nkinder has quit IRC02:23
*** su_zhang has joined #openstack-barbican02:25
*** su_zhang has quit IRC03:14
*** su_zhang has joined #openstack-barbican03:15
*** su_zhang has quit IRC03:19
*** su_zhang has joined #openstack-barbican04:14
*** michauds has joined #openstack-barbican04:34
*** david-lyle has quit IRC04:37
*** pcaruana has quit IRC04:55
*** zz_dimtruck is now known as dimtruck05:02
*** jamielennox is now known as jamielennox|away05:18
*** jaosorior has joined #openstack-barbican05:23
openstackgerritTony Breeds proposed openstack/barbican: Support upper-constratints.txt in tox environments
*** sigmavirus has quit IRC05:46
*** eglute has quit IRC05:46
*** eglute has joined #openstack-barbican05:47
*** eglute has quit IRC05:48
*** eglute has joined #openstack-barbican05:49
*** eglute has quit IRC05:49
*** eglute has joined #openstack-barbican05:50
*** eglute has quit IRC05:51
*** eglute has joined #openstack-barbican05:54
*** eglute has quit IRC05:54
*** eglute has joined #openstack-barbican06:05
*** michauds has quit IRC06:15
*** dimtruck is now known as zz_dimtruck06:27
*** pcaruana has joined #openstack-barbican06:52
*** andreas_s has joined #openstack-barbican06:59
*** su_zhang has quit IRC07:29
*** su_zhang has joined #openstack-barbican07:30
*** su_zhang has quit IRC07:34
*** su_zhang has joined #openstack-barbican07:40
*** su_zhang has quit IRC07:45
*** su_zhang has joined #openstack-barbican07:46
*** su_zhang has quit IRC07:50
*** jaosorior has quit IRC08:30
*** jaosorior has joined #openstack-barbican08:31
*** Kevin_Zheng has joined #openstack-barbican08:53
*** openstackgerrit has quit IRC11:03
*** openstackgerrit has joined #openstack-barbican11:04
*** crc32|znc has quit IRC11:27
*** crc32|znc has joined #openstack-barbican11:27
*** openstackstatus has quit IRC11:36
*** openstackstatus has joined #openstack-barbican11:37
*** ChanServ sets mode: +v openstackstatus11:37
*** woodster_ has joined #openstack-barbican11:42
*** jaosorior has quit IRC11:50
*** jaosorior has joined #openstack-barbican11:50
*** _sigmavirus24 has joined #openstack-barbican11:52
*** _sigmavirus24 is now known as sigmavirus11:54
*** sigmavirus has joined #openstack-barbican11:54
*** dave-mccowan has joined #openstack-barbican12:02
*** shohel has joined #openstack-barbican12:08
*** jaosorior is now known as jaosorior_brb12:26
*** shohel has quit IRC12:44
*** shohel has joined #openstack-barbican12:47
*** f13o has joined #openstack-barbican12:54
openstackgerritClenimar Filemon proposed openstack/python-barbicanclient: Cast sets to lists in acl functional tests
openstackgerritMerged openstack/castellan: Modify the home-page info
*** shohel has quit IRC13:36
*** shohel has joined #openstack-barbican13:36
*** shohel has quit IRC13:45
*** briancurtin has quit IRC13:51
*** briancurtin has joined #openstack-barbican13:52
*** zz_dimtruck is now known as dimtruck13:56
*** haplo37__ has joined #openstack-barbican14:11
*** su_zhang has joined #openstack-barbican14:19
*** spotz_zzz is now known as spotz14:32
*** randallburt has joined #openstack-barbican14:55
*** hockeynut has joined #openstack-barbican14:58
*** randallburt1 has joined #openstack-barbican14:59
*** jaosorior_brb is now known as jaosorior15:00
*** randallburt has quit IRC15:02
*** andreas_s has quit IRC15:18
*** f13o has quit IRC15:19
*** f13o has joined #openstack-barbican15:20
*** f13o has quit IRC15:26
*** Administrator__ has quit IRC15:36
*** Administrator__ has joined #openstack-barbican15:37
*** diazjf has joined #openstack-barbican15:38
*** f13o has joined #openstack-barbican15:38
*** su_zhang has quit IRC15:43
*** su_zhang has joined #openstack-barbican15:43
*** su_zhang has quit IRC15:44
*** su_zhang has joined #openstack-barbican15:44
*** su_zhang has quit IRC15:49
*** michauds has joined #openstack-barbican15:50
*** dgonzalez has quit IRC16:03
*** dgonzalez has joined #openstack-barbican16:05
*** dave-mccowan has quit IRC16:08
*** dave-mcc_ has joined #openstack-barbican16:08
*** diazjf has quit IRC16:13
*** pcaruana has quit IRC16:29
*** randallburt1 has quit IRC16:29
*** randallburt has joined #openstack-barbican16:31
*** dimtruck is now known as zz_dimtruck16:37
*** diazjf has joined #openstack-barbican16:39
*** jaosorior has quit IRC16:55
*** kfarr has joined #openstack-barbican16:55
*** diazjf has quit IRC17:01
*** su_zhang has joined #openstack-barbican17:01
*** su_zhang has quit IRC17:01
*** su_zhang has joined #openstack-barbican17:01
*** zz_dimtruck is now known as dimtruck17:12
*** edtubill has joined #openstack-barbican17:24
*** haplo37__ has quit IRC17:49
*** phschwartz has joined #openstack-barbican18:01
rm_workredrobot: you there? trying to remember if CertificateContainer has PK as optional or required18:02
*** earnThis has joined #openstack-barbican18:18
earnThiswhat is a KMIP connector?18:18
kfarrearnThis, what is the context?  Are you trying to set up Barbican w KMIP?18:27
earnThiskfarr: just trying to understand some licensing thing  I saw on another product. I thought the connectors were an industry standard thing, but i dont think they are18:29
earnThisalso, im pretty sure the "connectors" im dealing with are just based on the # of clients that access a key store via KMIP18:30
*** diazjf has joined #openstack-barbican18:47
*** su_zhang has quit IRC18:49
*** haplo37__ has joined #openstack-barbican18:57
*** earnThis has quit IRC19:18
*** earnThis has joined #openstack-barbican19:19
*** su_zhang has joined #openstack-barbican19:19
*** su_zhang has quit IRC19:26
*** haplo37__ has quit IRC19:26
openstackgerritArun Kant proposed openstack/barbican: Adding rest API for secret-stores resource (Part 4)
*** earnThis has left #openstack-barbican19:38
*** randallburt has quit IRC19:44
*** randallburt has joined #openstack-barbican19:45
*** su_zhang has joined #openstack-barbican20:08
*** diazjf has quit IRC20:32
*** diazjf has joined #openstack-barbican20:43
*** dimtruck is now known as zz_dimtruck20:45
*** zz_dimtruck is now known as dimtruck20:48
*** kfarr has quit IRC20:59
*** dgonzalez has quit IRC21:01
*** dgonzalez has joined #openstack-barbican21:03
*** randallburt has quit IRC21:34
*** randallburt has joined #openstack-barbican21:36
*** edtubill has quit IRC21:40
*** randallburt1 has joined #openstack-barbican21:40
*** randallburt has quit IRC21:43
redrobotarunkant there's some consistency issues with the API.  Once all secret-store reprensentations are consistent, then I will +2
arunkantredrobot: What is wrong in including secret store info on GET /secret-store/{id}/ ?22:05
arunkantredrobot: All of details API in barbican does that so any reason they need to be different.22:06
redrobotarunkant there's 3 different representations of a secret-store in the spec.  One without those properties, one with them, and one with just the ref.  I just care that all 3 representations are the same.  I assumed the one in the list, but if you want to keep those things in the API then make sure all representations include them.22:06
redrobotarunkant if you update to include those properties in all responses, then please rename "store_plugin" to "secret_store_plugin"22:08
redrobotarunkant  either way, if you add to all responses, or remove for all responses I will +222:08
arunkantredrobot: about 'secret-stores/{id}'  'secret-store/preferred' 'secret-stores/global-default' will include details  as each of them returns single item. In list, I can keep the current structure with 'name', 'global-default' and href22:09
redrobotarunkant why should list be different?  It would be easier for clients to parse responses if they're consistent.  Otherwise you need different logic to parse the list or to parse a single one22:10
arunkantredrobot: In barbican, typically list api are returning only href . I think we changed it to add couple of attributes as it can be useful.22:12
redrobotarunkant yes, I agree it would be useful.  That's why I would like the list of secret-stores to have the same properties as a single secret-store.  Why do you want them to be different?22:13
arunkantI was this in terms of REST API behavior as one is list API and others are returning single item..i.e can have details22:14
redrobotarunkant I was thinking since it's a list of secret-store objects, and the other responses are single secret-store objects, then all secret-store objects should be the same.22:15
*** jamielennox|away is now known as jamielennox22:15
redrobotarunkant otherwise clients that want to list the details in a UI for example would have to make a request for details to every single item on the list22:15
redrobotarunkant instead of just getting all details in the list call22:16
arunkantredrobot:  Okay..I can include all details though its different from other rest API behavior in barbican. Generally REST clients  does not expect full details in list.22:18
redrobotarunkant the more I think about it the more I'm not sure that the secret_store_plugin and crypto_plugin values should be in the api...22:24
*** spotz is now known as spotz_zzz22:24
redrobotarunkant since there's a user friendly name already, I can't think of why a client would care about the plugin details?22:25
redrobotarunkant what was the use case for including those?22:25
arunkantredrobot: it can be useful if someone wants to view/check what's the crypto plugin with DB backend vs PKCS11 . These are attributes of secret-store entry .22:27
arunkantredrobot : I know that's its p11_crypto ..but if you ask me after 3 months..I may not recall that . So its easier to just check with API as its already available.22:29
arunkantredrobot: I don't see supplying more details can be harmful . If someone does not need that, it can be easily disregarded.22:30
redrobotarunkant for Keystone, the objects in the lists match the same structure as the single objects22:32
redrobotarunkant check the apis for /domains and /domains/{domainId}22:33
redrobotarunkant and /users and /users/{userId}22:33
redrobotarunkant I think we should fix any APIs we have where an object in the list is different than the object when you get a single one22:34
arunkantredrobot: I don't think those API are listing create , update timestamp . Its just listing few attributes.  I have to check the actual outcome22:38
redrobotarunkant the point is that the JSON object is exactly the same in both API calls.  The actual attributes are not the same, since we care for different attributes in our project.22:39
arunkantredrobot: We can certainly update barbican list API behavior.  For now, I will update list to return items details as well as total entries are going to be short list.22:41
redrobotarunkant awesome,  I'll try to stay on top of the other reviews as well.  Thanks!22:41
arunkantredrobot: In general, list API does not tend to be same as details (if returned list is going to big) ..otherwise what's the point of having details API .22:42
redrobotarunkant do you have examples of OpenStack APIs where they are different?22:45
redrobotarunkant The API endpoint for a single item is useful for applying verbs to the resource e.g. to DELETE a single item, or to retrieve the properties when you already have the ID22:47
arunkantredrobot: I have to look into openstack API docs. I think there are example within barbican e.g.
redrobotarunkant yeah, but I think that's bad api design on our part.  see comment above about us having to fix that.22:53
arunkantredrobot: I have seen in other API docs.. if I recall nova API has something similar ..let me check22:55
arunkantredrobot: One example ..
*** randallburt1 has quit IRC22:59
redrobotarunkant they have an explicit api for listing with all details though22:59
redrobotarunkant which I guess kinda makes sense since the detailed object is so large...23:00
redrobotarunkant but the api change we're discussing is not that big23:00
*** hockeynut has quit IRC23:00
arunkantredrobot: yes..there is api for /details as well. I think ..there are number of places where list API and individual item attributes are going to be different because of list size or/and number of attributes can be returned in response23:00
redrobotarunkant yeah, I can see it making sense if you can avoid table joins...  but for our blueprint I think it makes more sense to keep them identical.  It's just a couple of properties and the benefit of a client being able to reuse parsing code makes it worth it I think23:02
arunkantredrobot: Yes, I agree. Its a short list so we can return all attributes . I will make change soon.23:03
*** diazjf has quit IRC23:09
*** tonyb has joined #openstack-barbican23:12
*** hockeynut has joined #openstack-barbican23:14
*** michauds has quit IRC23:17
*** dave-mcc_ has quit IRC23:23
*** dimtruck is now known as zz_dimtruck23:27
*** su_zhang has quit IRC23:37
*** su_zhang has joined #openstack-barbican23:38

Generated by 2.14.0 by Marius Gedminas - find it at!