-
Notifications
You must be signed in to change notification settings - Fork 185
Add tags instance filtering #2277
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @kt474! I have a couple of questions after reviewing the PR:
- the "resource_group" preference is set with the resource group ID, right? (I actually don't even know where to look for that)
- what will happen if someone sets a tag or resource group that doesn't exist? Do we know what is the intended behavior?
- the resource group unit test seems to be missing
I can only see the
I think we should refactor @francabrera what do you think? Update: We're just going to add filtering by tags |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good but I left a couple of questions regarding tests. Ideally, we should be able to mock the tag, plan_preference and region to test the backend retrieval directly, right?
Yeah we should be able to mock everything |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! thanks a lot. Just to quickly confirm, in the case where a list of tags contains a "correct" and an "incorrect" tag, as long as a backend is found through the correct tag, there isn't any error being raised, right? Would it make sense to raise a warning mentioning that no backends were found for a specific tag?
Currently, all tags have to match for backends to be returned. I believe this is the same behavior as the |
I think that the filter should fail if there is any incorrect tag in the list, just as you described. I was asking because I think that my early tests of |
Yeah |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I like the more indicative reno
* Add tags instance filtering (#2277) * wip add tags & resource group instance prefs * add resource_group preference * add reno * add test * remove resource group & raise error correctly * reno typo * update integration test * add unit test * update tests and release note * Fix small typos (#2299) * fix typo in base_runtime_job.py estimation infromation for this job. -> estimation information for this job. * fix typo in runtime_job_v2.py primitive exeuction. -> primitive execution. * fix typo in noise_learner.py layers that occurr more frequently. -> layers that occur more frequently. * fix typo (#2302) * Handle new IQP inconsistencies/breaking changes (#2296) * new IQP breaking changes * remove delete_job test * add release note * remove instance RuntimeOption * deprecate properly * typo * fix reno & runtimeoptions, add test * address comments * Add queue_usage deprecation --------- Co-authored-by: ElePT <epenatap@gmail.com> * black --------- Co-authored-by: Kevin Tian <kevin.tian@ibm.com> Co-authored-by: Inho Choi <79438062+q-inho@users.noreply.github.com> Co-authored-by: Jessie Yu <jessieyu@us.ibm.com> Co-authored-by: ElePT <epenatap@gmail.com>
Summary
We decided to just add filtering instances by tags, not resource group. Also updated the error handlings so an error will be raised at service initialization if no instances match the filter params given.
Details and comments
Fixes #2259