Here's my attempt at more precise details.

On Sat, Jun 13, 2020 at 3:02 AM Daniel Beck <[email protected]> wrote:

>
>
> > On 12. Jun 2020, at 20:05, Slide <[email protected]> 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 [email protected].
> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHqnZTWwo8oMnNYE%3DbpVxoqt_paOdDHfiz_fB7GsAJHUQ%40mail.gmail.com.

Reply via email to