| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-03-14 | |||
| 16:12:35 | dtantsur | yeah, the default one | |
| 16:12:42 | elmiko | yikes! | |
| 16:12:51 | elmiko | did they raise their prices or something? | |
| 16:12:52 | dtantsur | I think it is $1400+ for me with all discounts | |
| 16:12:55 | elmiko | wow | |
| 16:13:03 | dtantsur | it's $250 per night | |
| 16:13:10 | dtantsur | + taxes if I recall correctly | |
| 16:13:11 | elmiko | for 1 week, 1400 seems about right | |
| 16:13:23 | elmiko | but i mean, it's not like that hotel is "downtown" | |
| 16:13:35 | dtantsur | well, wait | |
| 16:13:45 | dtantsur | this is a different place now, not the choo-choo hotel | |
| 16:13:50 | elmiko | oooh, ok | |
| 16:13:56 | elmiko | i thought it was the same | |
| 16:13:58 | gtema | Hyat | |
| 16:13:58 | dtantsur | it IS downtown, like very-very fancy downtown | |
| 16:14:11 | dtantsur | right | |
| 16:14:18 | edleafe | yeah, no trains for the Train summit | |
| 16:14:22 | elmiko | alright then, that seems more "reasonable" XD | |
| 16:15:23 | gtema | are there any additional discounts available? I get only 250$ per night | |
| 16:17:45 | gtema | wow, just recognized. If I am departing on 27.04 I am there on 28.04, so I need only 7 days, and not 8. Whew, -250$ | |
| 16:17:58 | elmiko | \o/ | |
| 16:19:48 | dtantsur | gtema: depends on your flight, but usually road to the west is the same day | |
| 16:20:17 | gtema | yes, you are right. Checking math of my daughter confused me. Hi-hi | |
| 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 | edleafe | instead of "you must work with tags this way!" | |
| 16:36:58 | elmiko | ++, certainly seems so | |
| 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 | edleafe | gtema: there is http://specs.openstack.org/openstack/api-sig/guidelines/tags.html#filtering-and-searching-by-tags | |
| 16:39:13 | elmiko | or on the merits of that type of search? | |
| 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 | gtema | :D | |
| 16:50:39 | elmiko | i had /thought/ that's what searchlight was about | |
| 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 | |