Here's my attempt at more precise details.
On Sat, Jun 13, 2020 at 3:02 AM Daniel Beck <m...@beckweb.net> wrote:
>
>
> > On 12. Jun 2020, at 20:05, Slide <slide.o....@gmail.com> wrote:
> >
> > Jenkins Server makes sense to me as well. I'll add as a topic for the
> next Governance meeting.
>
> It seems as if this thread so far lacks considerations regarding the
> implementation of such a decision. This is concerning because a
> superficially good solution may well turn out to bring challenges when it
> comes to implementing them.
>
> For example, right now, master is at /computer/(master)/ and its
> self-label (to build jobs on it) is 'master'. What would those look like
> with the term 'Jenkins Server'? URLs with spaces in them are annoying due
> to percent-encoding. While labels support spaces, it's a fairly annoying
> syntax to type and autocompletion for them doesn't work properly. IOW, this
> is going to be more difficult if we choose a composite term.
>
> Similarly, it could make sense for us to consider how the term would be
> translated into some of the more commonly used languages. Some of the
> proposed terms are probably not easily translated. ('Server' should be fine
> as it's such a common term in tech. 'Majordomo' OTOH?)
>
> It might even make sense to separate the "UI" part from the "node" part:
> Jenkins server makes sense for the former. A different term might make more
> sense for the latter (and it's even clearer with terms like 'controller':
> the master node controls nothing). 'Primary' could work except it sounds
> like it's a good idea to build there. 'Local' perhaps?
>
>
I like the idea of separating the "UI" part from the "node" part.
>
> > Please also make sure and weigh in on AllowList/DenyList and it's other
> derivatives.
>
>
> FWIW since I've struggled to think of notable examples in Jenkins outside
> system properties and basically deprecated features like agent-to-master
> ('agent-to-jenkins-server'?) security: In-Process Script Approval (Script
> Security) has whitelists.
>
>
>
> P.S.: But perhaps let's throw some consideration about the scope of
> necessary changes of any term into the mix so we don't end up with a
> never-ending mess like for 'agent', but are prepared to implement this more
> quickly.
>
> Assuming a similar scope (fix all the UI, fix the few locations in the
> code that aren't breaking changes, fix Javadoc, skip breaking code changes
> and introduce compatibility fallbacks like supporting both 'agent.jar' and
> 'slave.jar' URLs):
>
> - So far we probably should add the label 'master' to that node (only)
> when upgrading from an older Jenkins. Otherwise builds may be blocked.
> - Show an admin monitor if any other node has the new self-label for the
> replacement term. This can result in unexpected node assignment decisions.
> - …?
>
>
Using the word 'valet' instead of 'master' to refer to the node that
executes inside the original Jenkins Java process. Replace it with the
term you prefer
- Redirect requests from /computer/(master)/ to /computer/(valet)/
- Assign the label 'valet' to the node that executes inside the original
Jenkins process
-
- Assign the NODE_NAME="valet" env var to that node instead of
NODE_NAME="master"
- Replace 'master' with 'valet' in help-label.html for AbstractProject
- Change display name of root node from 'master' to 'valet'
- Change the Jenkins#getSelfLabel() to return the label atom of "valet"
instead of "master"
- Show an admin monitor if any other agent has the label 'valet'
- Convert tests that reference agent labeled 'master' to use label
'valet'
Things that would not change:
- The jenkins.security.Roles (internal concept only, not shown to users)
- Name of the key file in security/master.key (internal concept, not
shown to users)
> --
> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/4F7F25FE-09BD-47C0-9BE8-5EAA28FA8C18%40beckweb.net
> .
>
--
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHqnZTWwo8oMnNYE%3DbpVxoqt_paOdDHfiz_fB7GsAJHUQ%40mail.gmail.com.
