kubectl wait for multiple conditions feature

1,654 views
Skip to first unread message

Harsh Thakur

unread,
Nov 22, 2020, 3:14:06 AM11/22/20
to kubernetes-sig-cli
Hey folks,
I have taken this issue up: https://github.com/kubernetes/kubernetes/issues/95759 .
Issue creator has suggested to add support for multiple for statements. Instead of that, can we do this?
kubectl wait <resource> --for='condition1=Status=Value, conditiond2=Status=Value ' .

We could also have conditional operators like "AND" and "OR" inside it. For ex:

kubectl wait <resource> --for='condition1=Status=Value || conditiond2=Status=Value ' .

Please let me know your thoughts.

PS: I am a first time contributor to K8s, excited to work on this

Thanks,
Harsh Thakur

Ricardo Katz

unread,
Nov 23, 2020, 9:36:04 AM11/23/20
to Harsh Thakur, kubernetes-sig-cli
Hello and welcome :)

As I've already written in Slack, but for the sake of having some
historic context:

1) kubectl wait have an "issue" with waiting nonexistent objects ->
https://github.com/kubernetes/kubernetes/issues/83242
I've miserably failed to implement this, so just need to be sure that
the proposal for multiple conditions won't conflict with this issue
(maybe you also get some way to solve both)

2) IMO, you could have one type of condition: AND or OR. Maybe having
two would make the implementation really hard, also it would be good
to have some user cases/stories if people would like this sort of
complex thing in the wait command (like
-for='((condition1=Status=Value || conditiond2=Status=Value) &&
condition3=Status=Value)

3) For the implementation side, once decided if this is going to be a
complex or a simple syntax, I would recommend to use StringArrayVar
(https://godoc.org/github.com/spf13/pflag#StringArrayP) that allows
you to repeat the flag and populates an array, like:

--for=condition=Status=Value --for=condition2=Status=Value2
--for=condition3=Status=Value3 that turns into
[]string{"condition=Status=Value"."condition2=Status=Value2","condition3=Status=Value3"}

4) Maybe creating a new flag (like --for-complex) as this seems to
change the behavior of --for :)
> --
> You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/e66ec0a9-f672-4552-a779-26a3148a046dn%40googlegroups.com.

Antoine Pelisse

unread,
Nov 23, 2020, 11:43:20 AM11/23/20
to Ricardo Katz, Harsh Thakur, kubernetes-sig-cli
On Mon, Nov 23, 2020 at 6:36 AM Ricardo Katz <ricard...@gmail.com> wrote:
Hello and welcome :)

As I've already written in Slack, but for the sake of having some
historic context:

1) kubectl wait have an "issue" with waiting nonexistent objects ->
https://github.com/kubernetes/kubernetes/issues/83242
I've miserably failed to implement this, so just need to be sure that
the proposal for multiple conditions won't conflict with this issue
(maybe you also get some way to solve both)

2) IMO, you could have one type of condition: AND or OR. Maybe having
two would make the implementation really hard, also it would be good
to have some user cases/stories if people would like this sort of
complex thing in the wait command (like
-for='((condition1=Status=Value || conditiond2=Status=Value) &&
condition3=Status=Value)

I'd also pick either AND or OR for syntax simplicity reasons. Since one can
serially wait for multiple condition by running multiple `kubectl
wait` serially (equivalent of AND), I would suggest that `kubectl
wait` should use OR internally, e.g.:

wait for (A || B) && (B || C)

would give:
kubectl wait --for=A --for=B; kubectl wait --for=B --for=C

Using De Morgan's law, you can probably turn expressions into
something that is "separated by ANDs".

3) For the implementation side, once decided if this is going to be a
complex or a simple syntax, I would recommend to use StringArrayVar
(https://godoc.org/github.com/spf13/pflag#StringArrayP) that allows
you to repeat the flag and populates an array, like:

--for=condition=Status=Value --for=condition2=Status=Value2
--for=condition3=Status=Value3 that turns into
[]string{"condition=Status=Value"."condition2=Status=Value2","condition3=Status=Value3"}

4) Maybe creating a new flag (like --for-complex) as this seems to
change the behavior of --for :)

I'm not sure this changes `--for` in an incompatible/confusing way.
 
On Sun, Nov 22, 2020 at 5:14 AM Harsh Thakur <harshth...@gmail.com> wrote:
>
> Hey folks,
> I have taken this issue up: https://github.com/kubernetes/kubernetes/issues/95759 .
> Issue creator has suggested to add support for multiple for statements. Instead of that, can we do this?
> kubectl wait <resource> --for='condition1=Status=Value, conditiond2=Status=Value ' .
>
> We could also have conditional operators like "AND" and "OR" inside it. For ex:
>
> kubectl wait <resource> --for='condition1=Status=Value || conditiond2=Status=Value ' .
>
> Please let me know your thoughts.
>
> PS: I am a first time contributor to K8s, excited to work on this
>
> Thanks,
> Harsh Thakur
>
> --
> You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/e66ec0a9-f672-4552-a779-26a3148a046dn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.

Harsh Thakur

unread,
Nov 24, 2020, 3:33:11 AM11/24/20
to Antoine Pelisse, Ricardo Katz, kubernetes-sig-cli
Thanks Antoine and Ricardo .
I'll take a look into the non-existent objects issue.
I really liked Antoine's idea of just supporting OR . If we use that, we won't need to have the "for complex" flag, I think.



Reply all
Reply to author
Forward
0 new messages