> 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?
> 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.
- …?
--
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.
