| *** dave-mccowan has joined #openstack-barbican | 01:02 | |
| *** dave-mccowan has quit IRC | 01:02 | |
| *** nkinder has quit IRC | 02:23 | |
| *** su_zhang has joined #openstack-barbican | 02:25 | |
| *** su_zhang has quit IRC | 03:14 | |
| *** su_zhang has joined #openstack-barbican | 03:15 | |
| *** su_zhang has quit IRC | 03:19 | |
| *** su_zhang has joined #openstack-barbican | 04:14 | |
| *** michauds has joined #openstack-barbican | 04:34 | |
| *** david-lyle has quit IRC | 04:37 | |
| *** pcaruana has quit IRC | 04:55 | |
| *** zz_dimtruck is now known as dimtruck | 05:02 | |
| *** jamielennox is now known as jamielennox|away | 05:18 | |
| *** jaosorior has joined #openstack-barbican | 05:23 | |
| openstackgerrit | Tony Breeds proposed openstack/barbican: Support upper-constratints.txt in tox environments https://review.openstack.org/358404 | 05:34 |
|---|---|---|
| *** sigmavirus has quit IRC | 05:46 | |
| *** eglute has quit IRC | 05:46 | |
| *** eglute has joined #openstack-barbican | 05:47 | |
| *** eglute has quit IRC | 05:48 | |
| *** eglute has joined #openstack-barbican | 05:49 | |
| *** eglute has quit IRC | 05:49 | |
| *** eglute has joined #openstack-barbican | 05:50 | |
| *** eglute has quit IRC | 05:51 | |
| *** eglute has joined #openstack-barbican | 05:54 | |
| *** eglute has quit IRC | 05:54 | |
| *** eglute has joined #openstack-barbican | 06:05 | |
| *** michauds has quit IRC | 06:15 | |
| *** dimtruck is now known as zz_dimtruck | 06:27 | |
| *** pcaruana has joined #openstack-barbican | 06:52 | |
| *** andreas_s has joined #openstack-barbican | 06:59 | |
| *** su_zhang has quit IRC | 07:29 | |
| *** su_zhang has joined #openstack-barbican | 07:30 | |
| *** su_zhang has quit IRC | 07:34 | |
| *** su_zhang has joined #openstack-barbican | 07:40 | |
| *** su_zhang has quit IRC | 07:45 | |
| *** su_zhang has joined #openstack-barbican | 07:46 | |
| *** su_zhang has quit IRC | 07:50 | |
| *** jaosorior has quit IRC | 08:30 | |
| *** jaosorior has joined #openstack-barbican | 08:31 | |
| *** Kevin_Zheng has joined #openstack-barbican | 08:53 | |
| *** openstackgerrit has quit IRC | 11:03 | |
| *** openstackgerrit has joined #openstack-barbican | 11:04 | |
| *** crc32|znc has quit IRC | 11:27 | |
| *** crc32|znc has joined #openstack-barbican | 11:27 | |
| *** openstackstatus has quit IRC | 11:36 | |
| *** openstackstatus has joined #openstack-barbican | 11:37 | |
| *** ChanServ sets mode: +v openstackstatus | 11:37 | |
| *** woodster_ has joined #openstack-barbican | 11:42 | |
| *** jaosorior has quit IRC | 11:50 | |
| *** jaosorior has joined #openstack-barbican | 11:50 | |
| *** _sigmavirus24 has joined #openstack-barbican | 11:52 | |
| *** _sigmavirus24 is now known as sigmavirus | 11:54 | |
| *** sigmavirus has joined #openstack-barbican | 11:54 | |
| *** dave-mccowan has joined #openstack-barbican | 12:02 | |
| *** shohel has joined #openstack-barbican | 12:08 | |
| *** jaosorior is now known as jaosorior_brb | 12:26 | |
| *** shohel has quit IRC | 12:44 | |
| *** shohel has joined #openstack-barbican | 12:47 | |
| *** f13o has joined #openstack-barbican | 12:54 | |
| openstackgerrit | Clenimar Filemon proposed openstack/python-barbicanclient: Cast sets to lists in acl functional tests https://review.openstack.org/351844 | 12:59 |
| openstackgerrit | Merged openstack/castellan: Modify the home-page info https://review.openstack.org/357899 | 13:06 |
| *** shohel has quit IRC | 13:36 | |
| *** shohel has joined #openstack-barbican | 13:36 | |
| *** shohel has quit IRC | 13:45 | |
| *** briancurtin has quit IRC | 13:51 | |
| *** briancurtin has joined #openstack-barbican | 13:52 | |
| *** zz_dimtruck is now known as dimtruck | 13:56 | |
| *** haplo37__ has joined #openstack-barbican | 14:11 | |
| *** su_zhang has joined #openstack-barbican | 14:19 | |
| *** spotz_zzz is now known as spotz | 14:32 | |
| *** randallburt has joined #openstack-barbican | 14:55 | |
| *** hockeynut has joined #openstack-barbican | 14:58 | |
| *** randallburt1 has joined #openstack-barbican | 14:59 | |
| *** jaosorior_brb is now known as jaosorior | 15:00 | |
| *** randallburt has quit IRC | 15:02 | |
| *** andreas_s has quit IRC | 15:18 | |
| *** f13o has quit IRC | 15:19 | |
| *** f13o has joined #openstack-barbican | 15:20 | |
| *** f13o has quit IRC | 15:26 | |
| *** Administrator__ has quit IRC | 15:36 | |
| *** Administrator__ has joined #openstack-barbican | 15:37 | |
| *** diazjf has joined #openstack-barbican | 15:38 | |
| *** f13o has joined #openstack-barbican | 15:38 | |
| *** su_zhang has quit IRC | 15:43 | |
| *** su_zhang has joined #openstack-barbican | 15:43 | |
| *** su_zhang has quit IRC | 15:44 | |
| *** su_zhang has joined #openstack-barbican | 15:44 | |
| *** su_zhang has quit IRC | 15:49 | |
| *** michauds has joined #openstack-barbican | 15:50 | |
| *** dgonzalez has quit IRC | 16:03 | |
| *** dgonzalez has joined #openstack-barbican | 16:05 | |
| *** dave-mccowan has quit IRC | 16:08 | |
| *** dave-mcc_ has joined #openstack-barbican | 16:08 | |
| *** diazjf has quit IRC | 16:13 | |
| *** pcaruana has quit IRC | 16:29 | |
| *** randallburt1 has quit IRC | 16:29 | |
| *** randallburt has joined #openstack-barbican | 16:31 | |
| *** dimtruck is now known as zz_dimtruck | 16:37 | |
| *** diazjf has joined #openstack-barbican | 16:39 | |
| *** jaosorior has quit IRC | 16:55 | |
| *** kfarr has joined #openstack-barbican | 16:55 | |
| *** diazjf has quit IRC | 17:01 | |
| *** su_zhang has joined #openstack-barbican | 17:01 | |
| *** su_zhang has quit IRC | 17:01 | |
| *** su_zhang has joined #openstack-barbican | 17:01 | |
| *** zz_dimtruck is now known as dimtruck | 17:12 | |
| *** edtubill has joined #openstack-barbican | 17:24 | |
| *** haplo37__ has quit IRC | 17:49 | |
| *** phschwartz has joined #openstack-barbican | 18:01 | |
| rm_work | redrobot: you there? trying to remember if CertificateContainer has PK as optional or required | 18:02 |
| *** earnThis has joined #openstack-barbican | 18:18 | |
| earnThis | what is a KMIP connector? | 18:18 |
| kfarr | earnThis, what is the context? Are you trying to set up Barbican w KMIP? | 18:27 |
| earnThis | kfarr: 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 are | 18:29 |
| earnThis | also, im pretty sure the "connectors" im dealing with are just based on the # of clients that access a key store via KMIP | 18:30 |
| *** diazjf has joined #openstack-barbican | 18:47 | |
| *** su_zhang has quit IRC | 18:49 | |
| *** haplo37__ has joined #openstack-barbican | 18:57 | |
| *** earnThis has quit IRC | 19:18 | |
| *** earnThis has joined #openstack-barbican | 19:19 | |
| *** su_zhang has joined #openstack-barbican | 19:19 | |
| *** su_zhang has quit IRC | 19:26 | |
| *** haplo37__ has quit IRC | 19:26 | |
| openstackgerrit | Arun Kant proposed openstack/barbican: Adding rest API for secret-stores resource (Part 4) https://review.openstack.org/358162 | 19:31 |
| *** earnThis has left #openstack-barbican | 19:38 | |
| *** randallburt has quit IRC | 19:44 | |
| *** randallburt has joined #openstack-barbican | 19:45 | |
| *** su_zhang has joined #openstack-barbican | 20:08 | |
| *** diazjf has quit IRC | 20:32 | |
| *** diazjf has joined #openstack-barbican | 20:43 | |
| *** dimtruck is now known as zz_dimtruck | 20:45 | |
| *** zz_dimtruck is now known as dimtruck | 20:48 | |
| *** kfarr has quit IRC | 20:59 | |
| *** dgonzalez has quit IRC | 21:01 | |
| *** dgonzalez has joined #openstack-barbican | 21:03 | |
| *** randallburt has quit IRC | 21:34 | |
| *** randallburt has joined #openstack-barbican | 21:36 | |
| *** edtubill has quit IRC | 21:40 | |
| *** randallburt1 has joined #openstack-barbican | 21:40 | |
| *** randallburt has quit IRC | 21:43 | |
| redrobot | arunkant there's some consistency issues with the API. Once all secret-store reprensentations are consistent, then I will +2 https://review.openstack.org/#/c/263972/18 | 22:03 |
| arunkant | redrobot: What is wrong in including secret store info on GET /secret-store/{id}/ ? | 22:05 |
| arunkant | redrobot: All of details API in barbican does that so any reason they need to be different. | 22:06 |
| redrobot | arunkant 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 |
| redrobot | arunkant if you update to include those properties in all responses, then please rename "store_plugin" to "secret_store_plugin" | 22:08 |
| redrobot | arunkant either way, if you add to all responses, or remove for all responses I will +2 | 22:08 |
| arunkant | redrobot: Okay..how 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 href | 22:09 |
| redrobot | arunkant 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 one | 22:10 |
| arunkant | redrobot: 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 |
| redrobot | arunkant 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 |
| arunkant | I was this in terms of REST API behavior as one is list API and others are returning single item..i.e can have details | 22:14 |
| arunkant | s/this/thinking | 22:14 |
| redrobot | arunkant 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 jamielennox | 22:15 | |
| redrobot | arunkant 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 list | 22:15 |
| redrobot | arunkant instead of just getting all details in the list call | 22:16 |
| arunkant | redrobot: 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 |
| redrobot | arunkant 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_zzz | 22:24 | |
| redrobot | arunkant since there's a user friendly name already, I can't think of why a client would care about the plugin details? | 22:25 |
| redrobot | arunkant what was the use case for including those? | 22:25 |
| arunkant | redrobot: 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 |
| arunkant | redrobot : 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 |
| arunkant | redrobot: I don't see supplying more details can be harmful . If someone does not need that, it can be easily disregarded. | 22:30 |
| redrobot | arunkant for Keystone, the objects in the lists match the same structure as the single objects | 22:32 |
| redrobot | arunkant check the apis for /domains and /domains/{domainId} | 22:33 |
| redrobot | arunkant and /users and /users/{userId} | 22:33 |
| redrobot | arunkant 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 one | 22:34 |
| arunkant | redrobot: I don't think those API are listing create , update timestamp . Its just listing few attributes. I have to check the actual outcome | 22:38 |
| redrobot | arunkant 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 |
| arunkant | redrobot: 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 |
| redrobot | arunkant awesome, I'll try to stay on top of the other reviews as well. Thanks! | 22:41 |
| arunkant | redrobot: 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 |
| redrobot | arunkant do you have examples of OpenStack APIs where they are different? | 22:45 |
| redrobot | arunkant 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 ID | 22:47 |
| arunkant | redrobot: I have to look into openstack API docs. I think there are example within barbican e.g. http://docs.openstack.org/developer/barbican/api/reference/cas.html | 22:52 |
| redrobot | arunkant yeah, but I think that's bad api design on our part. see comment above about us having to fix that. | 22:53 |
| arunkant | redrobot: I have seen in other API docs.. if I recall nova API has something similar ..let me check | 22:55 |
| arunkant | redrobot: One example ..http://developer.openstack.org/api-ref-compute-v2.1.html#listServers | 22:57 |
| *** randallburt1 has quit IRC | 22:59 | |
| redrobot | arunkant they have an explicit api for listing with all details though | 22:59 |
| redrobot | arunkant which I guess kinda makes sense since the detailed object is so large... | 23:00 |
| redrobot | arunkant but the api change we're discussing is not that big | 23:00 |
| *** hockeynut has quit IRC | 23:00 | |
| arunkant | redrobot: 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 response | 23:00 |
| redrobot | arunkant 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 think | 23:02 |
| arunkant | redrobot: Yes, I agree. Its a short list so we can return all attributes . I will make change soon. | 23:03 |
| *** diazjf has quit IRC | 23:09 | |
| *** tonyb has joined #openstack-barbican | 23:12 | |
| *** hockeynut has joined #openstack-barbican | 23:14 | |
| *** michauds has quit IRC | 23:17 | |
| *** dave-mcc_ has quit IRC | 23:23 | |
| *** dimtruck is now known as zz_dimtruck | 23:27 | |
| *** su_zhang has quit IRC | 23:37 | |
| *** su_zhang has joined #openstack-barbican | 23:38 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!