Why don't disable DNS Multicast by default?

[Francisco Javier Fernandez]

Hi all!

There are many opened issues related to DNS Multicast. The version of JmDNS used by Jenkins is an old one. Many of them should be fixed updating it (PR already opened), but also I'm wondering if it's worth to change the default behaviour and disable it, so anyone who wants this feature enabled should use the hudson.DNSMultiCast.disabled system property. It does not seem to be a widely used feature.

Thoughts?

Best regards,

Francisco J. Fernandez

[Adrien Lecharpentier]

If we disable the feature by default (which I think is a good idea), maybe we could rename the system property to "enabled". I have issues with double negatives.

--
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/401769a0-d616-4557-8079-f6ad26403d14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adrien Lecharpentier

[Oleg Nenashev]

I am fine with removing it by default.

Maybe it even worth detaching this code to a plugin

On Friday, May 17, 2019 at 12:36:35 PM UTC+2, Adrien Lecharpentier wrote:

If we disable the feature by default (which I think is a good idea), maybe we could rename the system property to "enabled". I have issues with double negatives.

Le ven. 17 mai 2019 à 12:08, Francisco Javier Fernandez <fjfer...@cloudbees.com> a écrit :

Hi all!

There are many opened issues related to DNS Multicast. The version of JmDNS used by Jenkins is an old one. Many of them should be fixed updating it (PR already opened), but also I'm wondering if it's worth to change the default behaviour and disable it, so anyone who wants this feature enabled should use the hudson.DNSMultiCast.disabled system property. It does not seem to be a widely used feature.

Thoughts?

Best regards,

Francisco J. Fernandez

--
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 jenkin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/401769a0-d616-4557-8079-f6ad26403d14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adrien Lecharpentier

[Arnaud Héritier]

+1

I don’t even remember why it was useful 😅

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/1321e7c9-72bc-4d66-b63e-32c757f72878%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Daniel Beck]

> On 25. May 2019, at 20:35, Arnaud Héritier <aher...@gmail.com> wrote:
>
> I don’t even remember why it was useful 😅

https://wiki.jenkins.io/display/JENKINS/Auto-discovering+Jenkins+on+the+network

[Daniel Beck]

> On 17. May 2019, at 12:08, Francisco Javier Fernandez <fjfer...@cloudbees.com> wrote:
>
> I'm wondering if it's worth to change the default behaviour and disable it, so anyone who wants this feature enabled should use the hudson.DNSMultiCast.disabled system property. It does not seem to be a widely used feature.

IIUC, the rationale for having these installed is for IT staff in large organizations to be able to discover Jenkins instances on their network, typically operated by developers wanting/needing to bypass red tape. Identifying these services is the first step to improve standardization/operations.

For that reason, anything but core-bundled, enabled-by-default means the feature might as well not exist.

[R. Tyler Croy]

(replies inline)

I think it's worth removing the feature. Frankly, if somebody needs multicast to find
a Jenkins server on their network, then they should probably not be considerd
IT/network admins. Finding a Jenkins instance in a big network is trivially
easy, as cryptominers have demonstrated quite effectively over the past couple
years ^_^


IMHO this is not a feature, but technical debt that's best removed.


Cheers

--
GitHub: https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

[Daniel Beck]

> On 26. May 2019, at 19:15, R. Tyler Croy <ty...@monkeypox.org> wrote:
>
> I think it's worth removing the feature. Frankly, if somebody needs multicast to find
> a Jenkins server on their network, then they should probably not be considerd
> IT/network admins. Finding a Jenkins instance in a big network is trivially
> easy, as cryptominers have demonstrated quite effectively over the past couple
> years ^_^
>
>
> IMHO this is not a feature, but technical debt that's best removed.

In that case we're probably better off just ripping these features out and _maybe_ writing a new plugin if enough users ask for it to be back. I.e. not the usual detachment dance. (There's no user data to be lost, and I'd be surprised if any classes were used in plugins.)

[Jesse Glick]

On Sat, May 25, 2019 at 2:31 PM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> Maybe it even worth detaching this code to a plugin

https://issues.jenkins-ci.org/browse/JENKINS-33596

[Francisco Javier Fernandez]

El jueves, 30 de mayo de 2019, 3:28:17 (UTC+2), Jesse Glick escribió:

On Sat, May 25, 2019 at 2:31 PM Oleg Nenashev <o.v.n...@gmail.com> wrote:
> Maybe it even worth detaching this code to a plugin

https://issues.jenkins-ci.org/browse/JENKINS-33596

That issue, although it's in progress seems to be paused since 8 months ago. Maybe what Daniel says makes sense: disable or remove it and create a new plugin, but not a detached one.

[Arnaud Héritier]

We can just ask on the users list if people are still using it and why?

--

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/1ee57cfa-4447-4686-84b7-b631015b594c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Jesse Glick]

On Thu, May 30, 2019 at 3:08 AM Francisco Javier Fernandez
<fjfer...@cloudbees.com> wrote:
> That issue, although it's in progress seems to be paused since 8 months ago.

I adjusted status accordingly. (Makes no sense for an issue with no
*Assignee* to be *In Progress* anyway!)

> Maybe what Daniel says makes sense: disable or remove it and create a new plugin, but not a detached one.

Basically the same thing, just comes down to whether after publishing
the newly split plugin you decide to include it in core’s list of
detached plugins or not. I agree that there is not a compelling
compatibility argument to do so.