Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create the concept of bot 'tags' similar to task tags. #293

Open
maruel opened this issue Jan 25, 2017 · 1 comment
Open

Create the concept of bot 'tags' similar to task tags. #293

maruel opened this issue Jan 25, 2017 · 1 comment

Comments

@maruel
Copy link
Member

maruel commented Jan 25, 2017

Background

Tasks have a concept of tags. While dimensions are meant to help with task->bot matching, tags are for management purposes. Tags are leveraged by /tasklist to provide efficient searchability and accounting mechanism. While dimensions are the what, tags are the why. The concept of task tags is relatively recent (2 years) but it is fully leveraged now.

At the present, bots can be searched for via their dimensions (the what) and a few special hardcoded special metadata like quarantined, is_busy and is_dead. See BotsRequest at appengine/swarming/swarming_rpcs.py#L413.

This is a significant limitation. Tasks were done first because Chrome manages around half a million tasks per day but only has a few thousands of bots, which meant that continuously enumerating all bots for each query was relatively acceptable but it is increasingly not. As the number of bots increases, manageability of bots becomes increasingly important.

There's no other way to search for bots without making this a dimension at the moment. Bots can expose state but it is intentionally fully unstructured data. This resulted in a fair amount of hardcoded logic in the Polymer UI; for example mp_lease_id
https://github.com/luci/luci-py/blob/master/appengine/swarming/ui/res/imp/botlist/bot-list.html#L366

To help with the explosion of metadata, _BotCommon.composite was added but it is inherently a hack and not extensible.

Goal

Make bots more consistent to tasks by using the same concepts of dimensions and tags. Transition the relevant subset of key:value style items from state into tags.

Similar to tasks, the server reserves the right add arbitrary tags.

This is to increase accountability of the bots, to expose more properties without necessarily making these attributes selectable for task selection. For example, a task shall not have the ability to select a Machine Provider managed VM or not. On the other hand, it is totally sensible for an administrator to search for all MP managed bots.

Action Items

Addition

Cleanup

  • Deprecate hardcoded quarantined and replace with special tag 'quarantined:0' or 'quarantined:1'.
  • Deprecate quarantined as either dimensions or state and migrate to a tag as quarantined:1 and quarantined_reasons:foo.
  • Update documentation Magic-Values.md.
  • Update indexes again to trim composite.
  • Remove hardcoded filters in bot-list.html.
@kjlubick
Copy link
Contributor

For tasks, the tags are basically a superset of the dimensions, and we always search by dimensions. Would this be the same for bots, i.e. you can only search by bot.tags? Or would we keep the search by dimensions and add a second api to search by tags?

I lean towards the former, for consistency and avoiding duplicate apis. In any case, I don't think a mixed search between dimensions and tags should be allowed.

I think is_dead and quarantined could become tags, as those are semi-permanent things.

I don't think is_busy should be a tag, as it is very transient, but I could be swayed on the matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants
@maruel @kjlubick and others