Earlier  
Posted Nick Remark
#openstack-sdks - 2019-03-14
16:11:39 gtema and from the whole travel the hotel is the most expensive - 2000$. It's crazy
16:12:12 dtantsur yeah, it's ridiculous. I even got a relatively cheap flight ("only" ~700 EUR). but the hotel...
16:12:27 elmiko is that the denver renaissance hotel that is $2000?
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

Earlier   Later