How should we treat OSB tags?

[pmorie]

The OSB API provides tags, a list of strings, to do the type of filtering that kubernetes uses labels for. This issue is to determine if we should:

1. Just use tags to do the type of search that CF does using tags
2. Translate tags into label selectors somehow and use label selection
3. Something else TBD

cc @jwforres

[jwforres]

FYI @dtaylor113 @jeff-phillips-18 tags are how we would categorize and filter things

[pmorie]

Moving to 0.0.3 because we will not get to it before then.

[arschles]

Moving this into 0.1.0 since we will need to decide on OSB tags before we provide backward-compatibility guarantees by then

[duglin]

Since labels and annotations are name/value pairs, but tags are just strings it doesn't seem like there's a good spot put them on the kueb core resource model. This would seem to then imply that we're probably going to have to keep this info in our own property - like we have now. Its just too bad that we can't easily search over it with some native kube search facility. We should have a brief chat about this but I'd suggest we close this issue.

[pmorie]

We could also remove both 'tags' and 'requires' and figure out how to treat them later.

…

On Fri, May 12, 2017 at 9:08 PM, Doug Davis ***@***.***> wrote: Since labels and annotations are name/value pairs, but tags are just strings it doesn't seem like there's a good spot put them on the kueb core resource model. This would seem to then imply that we're probably going to have to keep this info in our own property - like we have now. Its just too bad that we can't easily search over it with some native kube search facility. We should have a brief chat about this but I'd suggest we close this issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#497 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWXmJvxGB_ny72LGCIF_LHjTzPhosIjks5r5QKbgaJpZM4MXNFR> .

[duglin]

true, that would be the super safe option for beta.

Haven't thought much about 'requires' yet - does anyone think it would ever be more than just an array of strings to us? I know at some point we'll need to look at it and perhaps do something (like reject a serviceClass if we don't support one of the "requires") but would we ever store it as something else?

[jwforres]

Please do not remove tags completely, if you want to change it to an alpha field until you decide what to do long term that's fine.

[pmorie]

I will open a PR to change the name of Tags to AlphaTags after #843 is merged

[arschles]

We're moving all OSB* tags to alpha. Moving to 1.0.0

[duglin]

to be clear, its just one property "OSBTags" we're moving, not all OSB properties

[MHBauer]

This isn't closed by #861 or #1180. We still don't handle tags, but they're described as alpha.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[mszostok]

/remove-lifecycle rotten
/lifecycle frozen

[mrbobbytables]

This project is being archived, closing open issues and PRs.
Please see this PR for more information: kubernetes/community#6632