| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-03-14 | |||
| 16:20:26 | gtema | so back to 8 nights | |
| 16:21:42 | elmiko | /o\ | |
| 16:21:54 | edleafe | I added an item to the agenda https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda | |
| 16:22:09 | edleafe | "Discuss the advice on setting tags on existing resources. Why should that be a separate call? See https://review.openstack.org/#/c/642497/1/guidelines/tags.rst@141 for the background discussion. | |
| 16:22:29 | dtantsur | ah, that patch I was too lazy to review :) | |
| 16:23:17 | edleafe | Basically, it comes down to: why do tags need a distinct endpoint to be set? Why can't they be treated like any other attribute of a resource | |
| 16:23:18 | gtema | and I had absolutely no time to make a patch for keystone region configuration. Spending the whole day on the phone or writing emails | |
| 16:23:42 | elmiko | edleafe: that seems entirely reasonable to me, on the surface | |
| 16:24:22 | dtantsur | edleafe: it may depend on the exact API, I guess? | |
| 16:24:28 | dtantsur | if tags are just a field of an object - fine | |
| 16:24:59 | dtantsur | if you can do something like PUT /v1/bananas/b1/tags/VERY_TASTY, it's a bit different story | |
| 16:25:15 | gtema | I also dislike requirement to PUT tags in a separate call and sometimes need to fetch them separately | |
| 16:25:17 | elmiko | that latter style seems painful to some part of me | |
| 16:25:58 | edleafe | dtantsur: it's PUT /resouce/{id}/tags with a body containing the list of tags | |
| 16:26:21 | dtantsur | edleafe: then I agree with you | |
| 16:26:51 | edleafe | I'm not understanding why tags were considered special in the first place as far as URIs are concerned. The guidance about tag limitations make sense | |
| 16:27:38 | edleafe | Does anyone here know Miguel Grinberg? Git blame shows him as the primary author of that guideline | |
| 16:28:06 | dtantsur | The first time I hear this name | |
| 16:28:15 | elmiko | i know him | |
| 16:28:54 | elmiko | he was active in the "wg" when we first started, pretty sure you might have met him at one of those meetings edleafe | |
| 16:29:07 | elmiko | he's also highly active in the flask community | |
| 16:29:56 | edleafe | elmiko: do you recall any of the discussions about tag URIs? | |
| 16:30:38 | elmiko | edleafe: only very vaguely, dtantsur callout of the `PUT /v1/bananas/b1/tags/VERY_TASTY` kicks some dust, but not enough | |
| 16:31:15 | elmiko | fwiw, i tend to agree with the discussion now about making this like a normal resource update | |
| 16:32:22 | gtema | I would prefer if both ways work: normal resource op and a separate | |
| 16:32:59 | edleafe | Here is the original patch that created that guideline: https://review.openstack.org/#/c/155620/1/guidelines/tags.rst@15 | |
| 16:33:06 | elmiko | as far as guidance goes, i like the idea of prescribing the normal resource op, but not making that the /only/ option | |
| 16:33:16 | edleafe | well, ignore the @15 part | |
| 16:33:55 | edleafe | but it seems that the idea was to give the ability to set and delete individual tags using /resource/{id}/tags/foo | |
| 16:34:04 | edleafe | with no body | |
| 16:34:18 | elmiko | hmm, the "Tags Resource URLs" sheds some light on the reasoning imo | |
| 16:34:42 | elmiko | heh, you and me edleafe, just same thought train today lol | |
| 16:36:40 | edleafe | elmiko: so it seems that the idea is to provide some shortcuts when creating/deleting/searching tags | |
| 16:36:58 | elmiko | ++, certainly seems so | |
| 16:36:58 | edleafe | instead of "you must work with tags this way!" | |
| 16:37:11 | elmiko | "Note that this representation differs from the one adopted by Nova." | |
| 16:37:13 | elmiko | XD | |
| 16:37:36 | gtema | btw about searching tags. Is there any guidance/service/project/etc to search all resources based on tags? | |
| 16:38:14 | elmiko | good question, i'm not sure immediately. would have to check | |
| 16:39:00 | elmiko | gtema: would that be guidance about creating an api for doing that type of search? | |
| 16:39:13 | elmiko | or on the merits of that type of search? | |
| 16:39:13 | edleafe | gtema: there is http://specs.openstack.org/openstack/api-sig/guidelines/tags.html#filtering-and-searching-by-tags | |
| 16:39:27 | edleafe | gtema: or did you mean something more? | |
| 16:39:42 | elmiko | edleafe++ | |
| 16:40:09 | gtema | well, I was meaning more global. I.e. in AWS you can search all different resource types having specific tag set | |
| 16:40:52 | elmiko | imo, that would be highly project dependent but could still follow the advice that edleafe linked | |
| 16:41:19 | elmiko | like if your project wanted it, why not have a `GET /all?tags=foo` or whatever makes sense | |
| 16:41:37 | elmiko | or are you talking about cross-project? | |
| 16:41:55 | gtema | well, even only project base is already a very good beginning | |
| 16:42:19 | gtema | this is to some extend same issue as with project cleanup - find everything in a project | |
| 16:43:15 | edleafe | gtema: and it would be an equally difficult task to do that across OpenStack | |
| 16:43:25 | gtema | but here users might mark all own resources with a specific tag and would probably like to find all resources they have created to clean them up | |
| 16:43:32 | gtema | edleafe: I know | |
| 16:43:46 | elmiko | yeah, for cross-project stuff i think about searchlight. weren't they doing stuff in this area about finding resources? | |
| 16:44:11 | gtema | that is simply something with exist as a ugly bad custom "solution" in our cloud | |
| 16:44:20 | edleafe | gtema: So I understand the benefit of resource cleanup when a project is deleted. What would the benefit of tag search be? | |
| 16:44:28 | gtema | s/with/which/ | |
| 16:44:47 | elmiko | gtema: have you seen https://wiki.openstack.org/wiki/Searchlight ? | |
| 16:44:52 | gtema | as a user I want to find all resources in a project, that belong to me | |
| 16:44:59 | gtema | no, not yet | |
| 16:45:54 | gtema | my problem is that I need to fight (and will definitely loose) the game - let us also use this project | |
| 16:46:27 | elmiko | i just remembered it as an effort to do something similar to what you are talking about | |
| 16:46:29 | gtema | use = install | |
| 16:46:55 | elmiko | understood | |
| 16:46:57 | gtema | ok, thanks for point. Will dig further | |
| 16:48:54 | gtema | one reasonable use case: I leave the company (or go for a longer vacation, etc) and would like to clean only my resources (which were tagged) from the shared project | |
| 16:50:05 | elmiko | makes sense to me | |
| 16:50:25 | elmiko | but like, you will need to query multiple servies to get that info | |
| 16:50:27 | edleafe | gtema: I agree that that would be useful. I just cringe at the thought of getting all OpenStack teams to implement it | |
| 16:50:39 | elmiko | i had /thought/ that's what searchlight was about | |
| 16:50:39 | gtema | :D | |
| 16:52:47 | elmiko | edleafe: cringe is a good reaction, iiuc searchlight uses elasticsearch to index all the info, so it's no lightweight solution | |
| 16:53:14 | gtema | definitely | |
| 16:53:51 | edleafe | elmiko: True, but again that requires that all OpenStack projects either a) agree to push their information to searchlight, or b) provide an API that searchlight can query for the info | |
| 16:54:01 | elmiko | right | |
| 16:54:18 | elmiko | and i am not sure how they addressed that issue, i just remember watching some cool talks and demos about it =) | |
| 16:56:59 | gtema | current list of supported OpenStack services are: Cinder, Designate, Glance, Neutron, Nova, Swift | |
| 16:57:02 | edleafe | Elasticsearch is pretty awesome. Getting OpenStack projects to agree on something isn't :) | |
| 16:57:08 | gtema | Each OpenStack service will place notifications for any state change in RabbitMQ | |
| 16:57:15 | elmiko | edleafe: LOL yes!!! | |
| 16:57:53 | gtema | that's what API-SIG is doing, isn't it ;-) | |
| 16:57:59 | edleafe | gtema: yeah, let's re-invent distributed databases! | |
| 16:58:16 | elmiko | gtema: well, we provide guidance but we have always said that we are not the api police ;) | |
| 16:58:58 | gtema | and that's sad. Sometimes the police (or even S.W.A.T.) is necessary to bring things back | |
| 16:59:04 | edleafe | Although we might look pretty snazzy in our API Police uniforms! | |
| 16:59:05 | elmiko | haha | |
| 16:59:45 | edleafe | gtema: unfortunately, OpenStack has always been more about not hurting anyone's feelings than creating great software | |
| 17:00:19 | gtema | thanks | |
| 17:00:29 | edleafe | Well, the office hour is over, and I have to run out for a bit. | |
| 17:00:54 | elmiko | well, also, in the beginning there was no api guidance and to empower open collaboration and development you kinda have to let everyone in if you don't have standards ;) | |
| 17:00:59 | elmiko | later edleafe o/ | |
| 17:01:28 | gtema | yeah | |
| 17:01:39 | elmiko | it's a tough issue | |
| 17:02:16 | gtema | I know. Closed-source is bad, but opensource has also problems | |
| 17:02:27 | elmiko | yup, no magic solutions | |
| 17:02:56 | elmiko | i'm gonna grab some lunch, take care o/ | |
| 17:03:29 | gtema | yup. have a nice day | |
| 23:15:03 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/openstacksdk master: Add "name" filter in "list" call when retrieving a single register https://review.openstack.org/637238 | |
| #openstack-sdks - 2019-03-15 | |||
| 04:21:21 | openstackgerrit | Rabi Mishra proposed openstack/keystoneauth master: Set Content-Type header explictly for LegacyJsonAdapter https://review.openstack.org/643505 | |
| 13:22:01 | openstackgerrit | sean mooney proposed openstack/python-openstackclient master: add openstack server recreate command https://review.openstack.org/643578 | |