CloudRetentionStartegy misses UI config and descriptor

60 views
Skip to first unread message

Kanstantsin Shautsou

unread,
Mar 28, 2015, 7:45:14 AM3/28/15
to jenkin...@googlegroups.com
Tried to re-use RetentionStrategy jelly chooser code and was surprised that not all strategies found by descriptor lookup.
Is there any reason why CloudRetentionStartegy and OnceRetentionStartegy has do descriptors and ui config page?
What will happen if i will use OnceRetentionStartegy with >1 executor number?
What will happen if i will use other retention strategies instead of Cloud strategies, i.e. Always? Should i expect that it will run slaves according to available limits and keep them always online? This sounds weird, but in theory it may work in docker-plugin like any DumbSlave and provide end-users ability to create different configurations.

Stephen Connolly

unread,
Mar 28, 2015, 9:35:29 AM3/28/15
to jenkin...@googlegroups.com


On Saturday, March 28, 2015, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:
Tried to re-use RetentionStrategy jelly chooser code and was surprised that not all strategies found by descriptor lookup.
Is there any reason why CloudRetentionStartegy and OnceRetentionStartegy has do descriptors and ui config page?

Are they only applicable to certain slave types? 

What will happen if i will use OnceRetentionStartegy with >1 executor number?

Not sure. For my equivalent strategy in operations center I do one build per executor and then stop, but I did code that logic specially
 
What will happen if i will use other retention strategies instead of Cloud strategies, i.e. Always? Should i expect that it will run slaves according to available limits and keep them always online? 

Yes
 
This sounds weird, but in theory it may work in docker-plugin like any DumbSlave and provide end-users ability to create different configurations.

Yep 

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/92fa961b-6147-4866-a47a-51926c1ea4c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Sent from my phone

Jesse Glick

unread,
Mar 28, 2015, 3:05:01 PM3/28/15
to Jenkins Dev

OnceRetentionStrategy has no descriptor because it makes no sense to select on a static slave, and clouds generally hardcode the desired strategy.

It cannot be used with multiple executors, that would make no sense either.

Kanstantsin Shautsou

unread,
Mar 28, 2015, 5:12:03 PM3/28/15
to jenkin...@googlegroups.com


On Saturday, March 28, 2015 at 10:05:01 PM UTC+3, Jesse Glick wrote:

OnceRetentionStrategy has no descriptor because it makes no sense to select on a static slave, and clouds generally hardcode the desired strategy.

1) Every plugin that uses it creates own UI form with different help files and UI, it will be good to provide a standard out-of-the box implementations. 
2) It extends Describable and has no descriptor for doing lookup, there is no way to provide choosing different Cloud strategies for end user like it done for Always/Simple.
 

It cannot be used with multiple executors, that would make no sense either.

3) Thing that DumbSlave is not compatible with this strategy is also under question, for example i want accept only one job and then delete DumbSlave. This is a question of how end user may want to use it. Running some slaves in certain time in cloud is also valid use case imho.
4) Why no sense? Some users wants to have 2 executers on slave  https://github.com/jenkinsci/docker-plugin/pull/174 . The only difference that i see between Once and Cloud that once supports not killing slave until durable task isn't end. Such slave may accept 2 or other number of executors and don't kill if they running.

From my viewpoint core should provide right implemented classes: descriptor+ui form or it should be converted to abstract https://github.com/jenkinsci/jenkins/commit/f62fff5c0ca5091e9e7bc5945ea3a582ee3db3a4
 

Jesse Glick

unread,
Mar 30, 2015, 10:13:27 AM3/30/15
to Jenkins Dev
On Sat, Mar 28, 2015 at 5:12 PM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
>> OnceRetentionStrategy has no descriptor because it makes no sense to
>> select on a static slave, and clouds generally hardcode the desired strategy.
>
> Every plugin that uses it creates own UI form with different help files and UI

Every plugin? Not that I am aware of. For example
DockerTemplate.provision is hardcoding it.

> there is no way to provide choosing different Cloud strategies for end user

I think this is intentional—in general for a Cloud, the user should
not have to choose a strategy, one should be selected by the plugin
author according to the nature of the cloud implementation. For some
clouds there is a reasonable choice between two or more modes but I am
not convinced that this is best expressed by offering an arbitrary
RetentionStrategy in a pulldown—not all of them will be appropriate in
this context.

> that DumbSlave is not compatible with this strategy is also under
> question, for example i want accept only one job and then delete DumbSlave.

This makes no sense. You would have to manually go and create a new
slave after every build. Who would do that?

> Some users wants to have 2 executers on slave

Then they should not be using OnceRetentionStrategy. (Though for a
Docker slave the only reason to do this is to save the startup & class
loading time for the slave agent, which seems a poor tradeoff compared
to the lack of isolation between builds.)

> The only difference
> that i see between Once and Cloud that once supports not killing slave until
> durable task isn't end.

The support for durable tasks is a side benefit. The main point is
killing the slave immediately once the single build finishes.
Previously there were many slightly different implementations of this
strategy.

Kanstantsin Shautsou

unread,
Mar 30, 2015, 2:22:31 PM3/30/15
to jenkin...@googlegroups.com

> On Mar 30, 2015, at 17:13, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> On Sat, Mar 28, 2015 at 5:12 PM, Kanstantsin Shautsou
> <kanstan...@gmail.com> wrote:
>>> OnceRetentionStrategy has no descriptor because it makes no sense to
>>> select on a static slave, and clouds generally hardcode the desired strategy.
>>
>> Every plugin that uses it creates own UI form with different help files and UI
>
> Every plugin? Not that I am aware of. For example
> DockerTemplate.provision is hardcoding it.
Yes, OnceRetentionStrategy is existed in core and i want to use help page from core
and not create bad help files/UI forms for every Cloud implementation.
As i see f.property() may work out-of-the box.
>
>
>> there is no way to provide choosing different Cloud strategies for end user
>
> I think this is intentional—in general for a Cloud, the user should
> not have to choose a strategy, one should be selected by the plugin
> author according to the nature of the cloud implementation. For some
> clouds there is a reasonable choice between two or more modes but I am
> not convinced that this is best expressed by offering an arbitrary
> RetentionStrategy in a pulldown—not all of them will be appropriate in
> this context.
imho Cloud is just a high-level abstraction that provides resources.
For DumbSlave they created and connected manually, for Cloud automatically.
>
>> that DumbSlave is not compatible with this strategy is also under
>> question, for example i want accept only one job and then delete DumbSlave.
>
> This makes no sense. You would have to manually go and create a new
> slave after every build. Who would do that?
Why should i do it manually if strategy exist and i can use it?
>
>> Some users wants to have 2 executers on slave
>
> Then they should not be using OnceRetentionStrategy. (Though for a
> Docker slave the only reason to do this is to save the startup & class
> loading time for the slave agent, which seems a poor tradeoff compared
> to the lack of isolation between builds.)
This reason is not technical, it how people using jenkins. For me it better to allow using
strategies and provide help pages for end-users instead of understanding their super weird use cases.
>
>> The only difference
>> that i see between Once and Cloud that once supports not killing slave until
>> durable task isn't end.
>
> The support for durable tasks is a side benefit. The main point is
> killing the slave immediately once the single build finishes.
> Previously there were many slightly different implementations of this
> strategy.
Should i create another one strategy that will be not limited with executors number but support durable execution?
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6nGESEvJ_S0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3GKoVVERYkcMeUidkuL4dHvjw5kB2CsgdkOT%2B9F%3D6GVA%40mail.gmail.com.

Jesse Glick

unread,
Mar 30, 2015, 5:48:19 PM3/30/15
to Jenkins Dev
On Mon, Mar 30, 2015 at 2:22 PM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
>>> DumbSlave is not compatible with this strategy is also under
>>> question, for example i want accept only one job and then delete DumbSlave.
>>
>> This makes no sense. You would have to manually go and create a new
>> slave after every build. Who would do that?
>
> Why should i do it manually if strategy exist and i can use it?

Maybe you did not understand what I said. If you have a DumbSlave with
an OnceRetentionStrategy, as soon as it runs its first build it will
be removed. Since dumb slaves have to be explicitly added, this would
be silly. So even offering this retention strategy on a dumb slave
would be very confusing to a user.

>>> Some users wants to have 2 executers on slave
>>
>> Then they should not be using OnceRetentionStrategy.
>
> This reason is not technical

It is certainly technical. This strategy is written to support one use
case: when the build finishes, the slave is deleted. Any other
behavior would require a different implementation.

> Should i create another one strategy that will be not limited with executors number but support durable execution?

If you want one. I know of no use case for one, since the usual
alternative strategy for cloud slaves is to delete the slave once it
has been idle for some time, which does not need to check for
ContinuableExecutable that I can see.

Kanstantsin Shautsou

unread,
Mar 30, 2015, 6:12:32 PM3/30/15
to jenkin...@googlegroups.com

> On Mar 31, 2015, at 00:48, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> On Mon, Mar 30, 2015 at 2:22 PM, Kanstantsin Shautsou
> <kanstan...@gmail.com> wrote:
>>>> DumbSlave is not compatible with this strategy is also under
>>>> question, for example i want accept only one job and then delete DumbSlave.
>>>
>>> This makes no sense. You would have to manually go and create a new
>>> slave after every build. Who would do that?
>>
>> Why should i do it manually if strategy exist and i can use it?
>
> Maybe you did not understand what I said. If you have a DumbSlave with
> an OnceRetentionStrategy, as soon as it runs its first build it will
> be removed. Since dumb slaves have to be explicitly added, this would
> be silly. So even offering this retention strategy on a dumb slave
> would be very confusing to a user.
This strategy will work as it will be described in help description.
It may have sense for accepting one shot job for some special testing for example.
>
>>>> Some users wants to have 2 executers on slave
>>>
>>> Then they should not be using OnceRetentionStrategy.
>>
>> This reason is not technical
>
> It is certainly technical. This strategy is written to support one use
> case: when the build finishes, the slave is deleted. Any other
> behavior would require a different implementation.
>
>> Should i create another one strategy that will be not limited with executors number but support durable execution?
>
> If you want one. I know of no use case for one, since the usual
> alternative strategy for cloud slaves is to delete the slave once it
> has been idle for some time, which does not need to check for
> ContinuableExecutable that I can see.
I mean that strategies can be more generic and universal. Is there any overhead for supporting numExecutors check?
With 1 executor it will act as Once.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6nGESEvJ_S0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3_OHBO2wBDezs_TF5Fty87Nf-u-3WKLoWmiC6%2Btvbi7g%40mail.gmail.com.

Jesse Glick

unread,
Mar 30, 2015, 6:50:30 PM3/30/15
to Jenkins Dev
On Mon, Mar 30, 2015 at 6:12 PM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
> This strategy will work as it will be described in help description.
> It may have sense for accepting one shot job for some special testing for example.

Adding an option to the UI that is almost guaranteed to be useless and
confusing.

> Is there any overhead for supporting numExecutors check?

Added code complexity for a feature with no clear use case.

Kanstantsin Shautsou

unread,
Mar 30, 2015, 7:54:14 PM3/30/15
to jenkin...@googlegroups.com

> On Mar 31, 2015, at 01:50, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> On Mon, Mar 30, 2015 at 6:12 PM, Kanstantsin Shautsou
> <kanstan...@gmail.com> wrote:
>> This strategy will work as it will be described in help description.
>> It may have sense for accepting one shot job for some special testing for example.
>
> Adding an option to the UI that is almost guaranteed to be useless and
> confusing.
ALWAYS strategy works fine with Docker, i expect DEMAND and SCHEDULED strategies to work fine also. I may miss something but as i see it works.

I can’t grab into existed UI Cloud strategies or even extend them.

CloudSlaveRetentionStrategy has hardcoded 10 minutes delay, no Descriptor.
CloudRetentionStrategy has ‘private int idleMinutes’ and has no getter.

Copy-paste with fixes may help, but why not provide well extensible classes in core?
>
>> Is there any overhead for supporting numExecutors check?
>
> Added code complexity for a feature with no clear use case.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/6nGESEvJ_S0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2FdJaoEGuTOA8u%3DPmiimV-rwVP19w7aht39ZiJ0Lj%2B-g%40mail.gmail.com.

Kanstantsin Shautsou

unread,
Apr 19, 2015, 6:30:48 PM4/19/15
to jenkin...@googlegroups.com


On Tuesday, March 31, 2015 at 12:48:19 AM UTC+3, Jesse Glick wrote:
On Mon, Mar 30, 2015 at 2:22 PM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
>>> DumbSlave is not compatible with this strategy is also under
>>> question, for example i want accept only one job and then delete DumbSlave.
>>
>> This makes no sense. You would have to manually go and create a new
>> slave after every build. Who would do that?
>
> Why should i do it manually if strategy exist and i can use it?

Maybe you did not understand what I said. If you have a DumbSlave with
an OnceRetentionStrategy, as soon as it runs its first build it will
be removed. Since dumb slaves have to be explicitly added, this would
be silly. So even offering this retention strategy on a dumb slave
would be very confusing to a user.

Jesse Glick

unread,
Apr 20, 2015, 10:27:14 AM4/20/15
to Jenkins Dev
On Sun, Apr 19, 2015 at 6:30 PM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
>> Since dumb slaves have to be explicitly added, this would
>> be silly. So even offering this retention strategy on a dumb slave
>> would be very confusing to a user.
>
> https://groups.google.com/forum/#!topic/jenkinsci-dev/CuSe3RgX3Xo

I saw that. This is a specialized use case. Probably the nodepool
should really be a Cloud. If it cannot be that, then there should be a
specialized plugin for use with nodepool which created slaves with
that strategy.
Reply all
Reply to author
Forward
0 new messages