> On Mar 30, 2015, at 17:13, Jesse Glick <[email protected]> wrote: > > On Sat, Mar 28, 2015 at 5:12 PM, Kanstantsin Shautsou > <[email protected]> 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 > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3GKoVVERYkcMeUidkuL4dHvjw5kB2CsgdkOT%2B9F%3D6GVA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout.
-- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/A7826B69-4828-49B7-8053-5403F65E35ED%40gmail.com. For more options, visit https://groups.google.com/d/optout.
