Fwd: [jira] [Resolved] (INFRA-14645) node requirements for jenkins job logging-log4net

[Dominik Psenner <dp...@gmail.com>]

Hi,

Chris just resolved our infra ticket regarding .net frameworks on the
windows nodes. This is a summary of the outcome:

> Chris Thistlethwaite resolved INFRA-14645.
> ------------------------------------------
>    Resolution: Fixed

>> 1. We have observed that none of the windows nodes appear to have
net-2.0 installed so we cannot build assemblies against it. Is it possible
to install it on one or more of the windows nodes? It may well be the case
that it is not possible to have .NET framework 2.0 installed when a newer
.NET framework is installed on the same windows os.

> 1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0
installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd also
argue that building for .Net 2 isn't something we can support if the tools
at hand only allow newer binaries.

To me this means that we can no longer build assemblies targeted against
the framework net-2.0. net-3.5 is the oldest we can get from jenkins. We'll
have to announce this soon.

>> 2. We have observed that windows-2012-3 does not have .NET framework 3.5
installed while the other two Windows nodes have it installed.

> 2. jenkins-win2012-3 has been updated to fall in line with the other
nodes.

This means we will no longer see intermittent build failures because of the
missing framework.

>> 3. As an improvement to the windows node labels we suggest to add
additional labels that match the installed .NET frameworks. Currently it is
rather unclear what the windows nodes actually can do and it would further
allow that not all windows nodes to have exactly the same components
installed. (i.e. windows-2012-1 could have the labels "Windows",
"dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..)

> 3. Agreed, the windows nodes could use more organized labeling, however,
we're currently keeping them all built out the same (or as close as
possible obviously) so we can maximize the few boxes we have. We just don't
have enough need to run specific Windows configurations.

Now that [2] is fixed, all windows nodes have the same capabilities and
therefore this is not an issue.

Cheers,
Dominik

Re: [jira] [Resolved] (INFRA-14645) node requirements for jenkins job logging-log4net

[Dominik Psenner <dp...@gmail.com>]

I have no information about who uses log4net and against which framework it
runs. It would be great to have this information. There is this:

https://www.microsoft.com/en-us/download/details.aspx?id=6523

{quote}
Microsoft .NET Framework Version 2.0 Redistributable Package (x64)
[...]
*Supported Operating System*

Windows Server 2003, Datacenter x64 Edition, Windows Server 2003,
Enterprise x64 Edition, Windows Server 2003, Standard x64 Edition, Windows
XP 64-bit

{quote}


I have no access to either one of those operating systems. I've the
impression that developers that target an application to one of those
operating systems do also have the resources to build log4net from source
in the rare case they would need the latest codebase. Note that it is easy
to retarget applications to a newer .net framework like 3.5 because the api
remained backwards compatible. That's what one should do if he had to make
changes to an ancient application.

2017-08-30 17:31 GMT+02:00 Matt Sicker <bo...@gmail.com>:

> Oh well, so much for that idea. Do you think net-2.0 is still in wide
> enough use to continue supporting it? We moved on from Java 6 to 7 as
> baseline requirements for Log4j a while back even though there are still
> stragglers using 6, though the idea there is that most users still on 6
> aren't really updating anything anymore other than security patches if
> applicable. Would you say it's similar in .net 2?
>
> On 30 August 2017 at 02:39, Dominik Psenner <dp...@gmail.com> wrote:
>
> >
> > On 2017-08-29 16:12, Matt Sicker wrote:
> >
> >> I'm not too familiar with this area, but would using Windows containers
> >> (e.g., via Docker or similar) work here? Or would that only support
> newer
> >> versions of .net anyways?
> >>
> >
> > Good idea Matt, unfortunately net-2.0 is not available in a windows
> server
> > docker container as documented in the image variants section at
> > https://hub.docker.com/r/microsoft/dotnet-framework/. Only 3.5 and newer
> > are available. We already build net-3.5, net-4.0 and net-4.5 with
> jenkins.
> > I've the impression that if we changed this today, we would gain nothing.
> >
> >
> >
> >> On 28 August 2017 at 23:32, Dominik Psenner <dp...@gmail.com> wrote:
> >>
> >> Hi,
> >>>
> >>> Chris just resolved our infra ticket regarding .net frameworks on the
> >>> windows nodes. This is a summary of the outcome:
> >>>
> >>> Chris Thistlethwaite resolved INFRA-14645.
> >>>> ------------------------------------------
> >>>>     Resolution: Fixed
> >>>>
> >>>>> 1. We have observed that none of the windows nodes appear to have
> >>>>>
> >>>> net-2.0 installed so we cannot build assemblies against it. Is it
> >>> possible
> >>> to install it on one or more of the windows nodes? It may well be the
> >>> case
> >>> that it is not possible to have .NET framework 2.0 installed when a
> newer
> >>> .NET framework is installed on the same windows os.
> >>>
> >>> 1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0
> >>>>
> >>> installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd
> >>> also
> >>> argue that building for .Net 2 isn't something we can support if the
> >>> tools
> >>> at hand only allow newer binaries.
> >>>
> >>> To me this means that we can no longer build assemblies targeted
> against
> >>> the framework net-2.0. net-3.5 is the oldest we can get from jenkins.
> >>> We'll
> >>> have to announce this soon.
> >>>
> >>> 2. We have observed that windows-2012-3 does not have .NET framework
> 3.5
> >>>>>
> >>>> installed while the other two Windows nodes have it installed.
> >>>
> >>> 2. jenkins-win2012-3 has been updated to fall in line with the other
> >>>>
> >>> nodes.
> >>>
> >>> This means we will no longer see intermittent build failures because of
> >>> the
> >>> missing framework.
> >>>
> >>> 3. As an improvement to the windows node labels we suggest to add
> >>>>>
> >>>> additional labels that match the installed .NET frameworks. Currently
> >>> it is
> >>> rather unclear what the windows nodes actually can do and it would
> >>> further
> >>> allow that not all windows nodes to have exactly the same components
> >>> installed. (i.e. windows-2012-1 could have the labels "Windows",
> >>> "dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..)
> >>>
> >>> 3. Agreed, the windows nodes could use more organized labeling,
> however,
> >>>>
> >>> we're currently keeping them all built out the same (or as close as
> >>> possible obviously) so we can maximize the few boxes we have. We just
> >>> don't
> >>> have enough need to run specific Windows configurations.
> >>>
> >>> Now that [2] is fixed, all windows nodes have the same capabilities and
> >>> therefore this is not an issue.
> >>>
> >>> Cheers,
> >>> Dominik
> >>>
> >>>
> >>
> >>
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>



-- 
Dominik Psenner

Re: [jira] [Resolved] (INFRA-14645) node requirements for jenkins job logging-log4net

[Ralph Goers <ra...@dslextreme.com>]

For what it is worth, if you go to https://repository.apache.org/#central-stat <https://repository.apache.org/#central-stat> you can see that about 25% of the downloads for log4j-api are for versions that still support Java 6. Unfortunately, I don’t know of any way to detect how many users are still using Java 7 unless we can find a commons component that has a Java 7 and Java 8 version and look at those download stats. But if we have 1/4 or our users still on Java 6 I have to believe a larger number than that are using Java 7.

Ralph

> On Aug 30, 2017, at 8:31 AM, Matt Sicker <bo...@gmail.com> wrote:
> 
> Oh well, so much for that idea. Do you think net-2.0 is still in wide
> enough use to continue supporting it? We moved on from Java 6 to 7 as
> baseline requirements for Log4j a while back even though there are still
> stragglers using 6, though the idea there is that most users still on 6
> aren't really updating anything anymore other than security patches if
> applicable. Would you say it's similar in .net 2?
> 
> On 30 August 2017 at 02:39, Dominik Psenner <dp...@gmail.com> wrote:
> 
>> 
>> On 2017-08-29 16:12, Matt Sicker wrote:
>> 
>>> I'm not too familiar with this area, but would using Windows containers
>>> (e.g., via Docker or similar) work here? Or would that only support newer
>>> versions of .net anyways?
>>> 
>> 
>> Good idea Matt, unfortunately net-2.0 is not available in a windows server
>> docker container as documented in the image variants section at
>> https://hub.docker.com/r/microsoft/dotnet-framework/. Only 3.5 and newer
>> are available. We already build net-3.5, net-4.0 and net-4.5 with jenkins.
>> I've the impression that if we changed this today, we would gain nothing.
>> 
>> 
>> 
>>> On 28 August 2017 at 23:32, Dominik Psenner <dp...@gmail.com> wrote:
>>> 
>>> Hi,
>>>> 
>>>> Chris just resolved our infra ticket regarding .net frameworks on the
>>>> windows nodes. This is a summary of the outcome:
>>>> 
>>>> Chris Thistlethwaite resolved INFRA-14645.
>>>>> ------------------------------------------
>>>>>    Resolution: Fixed
>>>>> 
>>>>>> 1. We have observed that none of the windows nodes appear to have
>>>>>> 
>>>>> net-2.0 installed so we cannot build assemblies against it. Is it
>>>> possible
>>>> to install it on one or more of the windows nodes? It may well be the
>>>> case
>>>> that it is not possible to have .NET framework 2.0 installed when a newer
>>>> .NET framework is installed on the same windows os.
>>>> 
>>>> 1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0
>>>>> 
>>>> installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd
>>>> also
>>>> argue that building for .Net 2 isn't something we can support if the
>>>> tools
>>>> at hand only allow newer binaries.
>>>> 
>>>> To me this means that we can no longer build assemblies targeted against
>>>> the framework net-2.0. net-3.5 is the oldest we can get from jenkins.
>>>> We'll
>>>> have to announce this soon.
>>>> 
>>>> 2. We have observed that windows-2012-3 does not have .NET framework 3.5
>>>>>> 
>>>>> installed while the other two Windows nodes have it installed.
>>>> 
>>>> 2. jenkins-win2012-3 has been updated to fall in line with the other
>>>>> 
>>>> nodes.
>>>> 
>>>> This means we will no longer see intermittent build failures because of
>>>> the
>>>> missing framework.
>>>> 
>>>> 3. As an improvement to the windows node labels we suggest to add
>>>>>> 
>>>>> additional labels that match the installed .NET frameworks. Currently
>>>> it is
>>>> rather unclear what the windows nodes actually can do and it would
>>>> further
>>>> allow that not all windows nodes to have exactly the same components
>>>> installed. (i.e. windows-2012-1 could have the labels "Windows",
>>>> "dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..)
>>>> 
>>>> 3. Agreed, the windows nodes could use more organized labeling, however,
>>>>> 
>>>> we're currently keeping them all built out the same (or as close as
>>>> possible obviously) so we can maximize the few boxes we have. We just
>>>> don't
>>>> have enough need to run specific Windows configurations.
>>>> 
>>>> Now that [2] is fixed, all windows nodes have the same capabilities and
>>>> therefore this is not an issue.
>>>> 
>>>> Cheers,
>>>> Dominik
>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 
> -- 
> Matt Sicker <bo...@gmail.com>

Re: [jira] [Resolved] (INFRA-14645) node requirements for jenkins job logging-log4net

[Matt Sicker <bo...@gmail.com>]

Oh well, so much for that idea. Do you think net-2.0 is still in wide
enough use to continue supporting it? We moved on from Java 6 to 7 as
baseline requirements for Log4j a while back even though there are still
stragglers using 6, though the idea there is that most users still on 6
aren't really updating anything anymore other than security patches if
applicable. Would you say it's similar in .net 2?

On 30 August 2017 at 02:39, Dominik Psenner <dp...@gmail.com> wrote:

>
> On 2017-08-29 16:12, Matt Sicker wrote:
>
>> I'm not too familiar with this area, but would using Windows containers
>> (e.g., via Docker or similar) work here? Or would that only support newer
>> versions of .net anyways?
>>
>
> Good idea Matt, unfortunately net-2.0 is not available in a windows server
> docker container as documented in the image variants section at
> https://hub.docker.com/r/microsoft/dotnet-framework/. Only 3.5 and newer
> are available. We already build net-3.5, net-4.0 and net-4.5 with jenkins.
> I've the impression that if we changed this today, we would gain nothing.
>
>
>
>> On 28 August 2017 at 23:32, Dominik Psenner <dp...@gmail.com> wrote:
>>
>> Hi,
>>>
>>> Chris just resolved our infra ticket regarding .net frameworks on the
>>> windows nodes. This is a summary of the outcome:
>>>
>>> Chris Thistlethwaite resolved INFRA-14645.
>>>> ------------------------------------------
>>>>     Resolution: Fixed
>>>>
>>>>> 1. We have observed that none of the windows nodes appear to have
>>>>>
>>>> net-2.0 installed so we cannot build assemblies against it. Is it
>>> possible
>>> to install it on one or more of the windows nodes? It may well be the
>>> case
>>> that it is not possible to have .NET framework 2.0 installed when a newer
>>> .NET framework is installed on the same windows os.
>>>
>>> 1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0
>>>>
>>> installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd
>>> also
>>> argue that building for .Net 2 isn't something we can support if the
>>> tools
>>> at hand only allow newer binaries.
>>>
>>> To me this means that we can no longer build assemblies targeted against
>>> the framework net-2.0. net-3.5 is the oldest we can get from jenkins.
>>> We'll
>>> have to announce this soon.
>>>
>>> 2. We have observed that windows-2012-3 does not have .NET framework 3.5
>>>>>
>>>> installed while the other two Windows nodes have it installed.
>>>
>>> 2. jenkins-win2012-3 has been updated to fall in line with the other
>>>>
>>> nodes.
>>>
>>> This means we will no longer see intermittent build failures because of
>>> the
>>> missing framework.
>>>
>>> 3. As an improvement to the windows node labels we suggest to add
>>>>>
>>>> additional labels that match the installed .NET frameworks. Currently
>>> it is
>>> rather unclear what the windows nodes actually can do and it would
>>> further
>>> allow that not all windows nodes to have exactly the same components
>>> installed. (i.e. windows-2012-1 could have the labels "Windows",
>>> "dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..)
>>>
>>> 3. Agreed, the windows nodes could use more organized labeling, however,
>>>>
>>> we're currently keeping them all built out the same (or as close as
>>> possible obviously) so we can maximize the few boxes we have. We just
>>> don't
>>> have enough need to run specific Windows configurations.
>>>
>>> Now that [2] is fixed, all windows nodes have the same capabilities and
>>> therefore this is not an issue.
>>>
>>> Cheers,
>>> Dominik
>>>
>>>
>>
>>
>


-- 
Matt Sicker <bo...@gmail.com>

Re: [jira] [Resolved] (INFRA-14645) node requirements for jenkins job logging-log4net

[Dominik Psenner <dp...@gmail.com>]

On 2017-08-29 16:12, Matt Sicker wrote:
> I'm not too familiar with this area, but would using Windows containers
> (e.g., via Docker or similar) work here? Or would that only support newer
> versions of .net anyways?

Good idea Matt, unfortunately net-2.0 is not available in a windows 
server docker container as documented in the image variants section at 
https://hub.docker.com/r/microsoft/dotnet-framework/. Only 3.5 and newer 
are available. We already build net-3.5, net-4.0 and net-4.5 with 
jenkins. I've the impression that if we changed this today, we would 
gain nothing.

>
> On 28 August 2017 at 23:32, Dominik Psenner <dp...@gmail.com> wrote:
>
>> Hi,
>>
>> Chris just resolved our infra ticket regarding .net frameworks on the
>> windows nodes. This is a summary of the outcome:
>>
>>> Chris Thistlethwaite resolved INFRA-14645.
>>> ------------------------------------------
>>>     Resolution: Fixed
>>>> 1. We have observed that none of the windows nodes appear to have
>> net-2.0 installed so we cannot build assemblies against it. Is it possible
>> to install it on one or more of the windows nodes? It may well be the case
>> that it is not possible to have .NET framework 2.0 installed when a newer
>> .NET framework is installed on the same windows os.
>>
>>> 1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0
>> installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd also
>> argue that building for .Net 2 isn't something we can support if the tools
>> at hand only allow newer binaries.
>>
>> To me this means that we can no longer build assemblies targeted against
>> the framework net-2.0. net-3.5 is the oldest we can get from jenkins. We'll
>> have to announce this soon.
>>
>>>> 2. We have observed that windows-2012-3 does not have .NET framework 3.5
>> installed while the other two Windows nodes have it installed.
>>
>>> 2. jenkins-win2012-3 has been updated to fall in line with the other
>> nodes.
>>
>> This means we will no longer see intermittent build failures because of the
>> missing framework.
>>
>>>> 3. As an improvement to the windows node labels we suggest to add
>> additional labels that match the installed .NET frameworks. Currently it is
>> rather unclear what the windows nodes actually can do and it would further
>> allow that not all windows nodes to have exactly the same components
>> installed. (i.e. windows-2012-1 could have the labels "Windows",
>> "dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..)
>>
>>> 3. Agreed, the windows nodes could use more organized labeling, however,
>> we're currently keeping them all built out the same (or as close as
>> possible obviously) so we can maximize the few boxes we have. We just don't
>> have enough need to run specific Windows configurations.
>>
>> Now that [2] is fixed, all windows nodes have the same capabilities and
>> therefore this is not an issue.
>>
>> Cheers,
>> Dominik
>>
>
>

Re: [jira] [Resolved] (INFRA-14645) node requirements for jenkins job logging-log4net

[Matt Sicker <bo...@gmail.com>]

I'm not too familiar with this area, but would using Windows containers
(e.g., via Docker or similar) work here? Or would that only support newer
versions of .net anyways?

On 28 August 2017 at 23:32, Dominik Psenner <dp...@gmail.com> wrote:

> Hi,
>
> Chris just resolved our infra ticket regarding .net frameworks on the
> windows nodes. This is a summary of the outcome:
>
> > Chris Thistlethwaite resolved INFRA-14645.
> > ------------------------------------------
> >    Resolution: Fixed
>
> >> 1. We have observed that none of the windows nodes appear to have
> net-2.0 installed so we cannot build assemblies against it. Is it possible
> to install it on one or more of the windows nodes? It may well be the case
> that it is not possible to have .NET framework 2.0 installed when a newer
> .NET framework is installed on the same windows os.
>
> > 1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0
> installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd also
> argue that building for .Net 2 isn't something we can support if the tools
> at hand only allow newer binaries.
>
> To me this means that we can no longer build assemblies targeted against
> the framework net-2.0. net-3.5 is the oldest we can get from jenkins. We'll
> have to announce this soon.
>
> >> 2. We have observed that windows-2012-3 does not have .NET framework 3.5
> installed while the other two Windows nodes have it installed.
>
> > 2. jenkins-win2012-3 has been updated to fall in line with the other
> nodes.
>
> This means we will no longer see intermittent build failures because of the
> missing framework.
>
> >> 3. As an improvement to the windows node labels we suggest to add
> additional labels that match the installed .NET frameworks. Currently it is
> rather unclear what the windows nodes actually can do and it would further
> allow that not all windows nodes to have exactly the same components
> installed. (i.e. windows-2012-1 could have the labels "Windows",
> "dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..)
>
> > 3. Agreed, the windows nodes could use more organized labeling, however,
> we're currently keeping them all built out the same (or as close as
> possible obviously) so we can maximize the few boxes we have. We just don't
> have enough need to run specific Windows configurations.
>
> Now that [2] is fixed, all windows nodes have the same capabilities and
> therefore this is not an issue.
>
> Cheers,
> Dominik
>



-- 
Matt Sicker <bo...@gmail.com>