The monit used in the standard stem cells is ancient and there are two PRs
to update it opened against bosh. I've been trying to understand what's
going on by making comments on one of the PRs but I think a discussion
would be easier here.

Can someone please explain why we a bump to monit 5.2.5 is not something
that can just be done and tested through the existing bosh pipeline?

Can someone please explain why moving beyond 5.2.5 is not possible? The
only thing I've seen referenced is "license issues"; quite nebulous. I
believe there was a move from GPLv3 to AGPL somewhere along the way but I'm
not sure of the significance of that given how monit is used.

Finally, there were comments on PR #937 implying that Bosh wants to replace
monit with something home grown. I have no issues with this but if it's
going to be used as a reason not to stay current with software (the monit
we're using is 4 years old), I feel like a proposal should at least be
floated so outside contributors are aware. It's hard to help when the
direction is not communicated.

Thanks.

--
Matthew Sykes
matthew.sykes(a)gmail.com

inline

Sent from my iPhone

On Sep 19, 2015, at 7:59 AM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote:

The monit used in the standard stem cells is ancient and there are two PRs to update it opened against bosh. I've been trying to understand what's going on by making comments on one of the PRs but I think a discussion would be easier here.

Can someone please explain why we a bump to monit 5.2.5 is not something that can just be done and tested through the existing bosh pipeline?

Existing bosh pipeline does very minimal testing of monit interoperability, partly because there is no dedicated test suite that test all kinds of cases. With changes that may affect all releases in unexpected ways, we typically try to get different teams to test the change before it's pulled into bosh. (Example: when we tried to properly wait for monit to stop, we didn't pull in that change because cf-release jobs started failing when nfs client was used. We will pull that change eventually when nfs is removed as a default from cf-release.)

It would be nice to have a test suite that just runs all kinds of releases against bosh for similar cases but we have not invested time in that yet.

What I suggested in one of the PR is for the team that's seeing an issue with monit 5.2.4 to build a stemcell with 5.2.5 and confirm that the issue is gone and doesn't cause any other side effects running in that environment. We don't see that issue in our environments so we cannot verify that bump would help. Since update to monit may introduce unrelated problems imho this is the quickest way to verify that bump is helpful.

Can someone please explain why moving beyond 5.2.5 is not possible? The only thing I've seen referenced is "license issues"; quite nebulous. I believe there was a move from GPLv3 to AGPL somewhere along the way but I'm not sure of the significance of that given how monit is used.

Agpl as I understand is on a lot of companies blacklists. If 5.2.5 update doesn't help the issue seen in that environment, we can spend time with CF Foundation figuring out if having monit being agpl is acceptable.

Finally, there were comments on PR #937 implying that Bosh wants to replace monit with something home grown. I have no issues with this but if it's going to be used as a reason not to stay current with software (the monit we're using is 4 years old), I feel like a proposal should at least be floated so outside contributors are aware. It's hard to help when the direction is not communicated.

Monit replacement ideas are just a hallway conversations.

We are not planning to replace monit any time soon due to other competing priorities like links, azs, stemcell hardening, backup, etc. When we do get to a point when it becomes a priority we will definitely share a proposal on bosh-notes with a community.

We are being conservative in how we bump monit since typically it affects all releases and figuring intricacies of monit especially when it's different versions is not a fun/productive activity.

Thanks.

--
Matthew Sykes
matthew.sykes(a)gmail.com

Dmitri wrote: "When we do get to a point when it becomes a priority we will definitely share a proposal on bosh-notes with a community."

We aren't asking for giggles.

As Matt said, in comments, we are running into issues that need to be worked around. Hence, it is a priority for us, and likely for those who have submitted PRs and issues.

AGPL can indeed be problematic, but I don't think we should discount it out of hand. The way monit is exposed and used in CF/BOSH with GPL was and is fine, so, copy-left isn't affecting the CF developed code/licensing. I suspect the same could be said for AGPL. Also, unless we or a user of BOSH changes the monit code, there's also no issue.

I suggest that we engage real lawyers to figure a way out of this issue; because as Matt has indicated, it is a problem/priority for some of us.

Matt has been trying to get the issue some attention. What do we need to do to get the priority discussion going in the BOSH PMC?

Thanks,

Chris



Sent from my iPhone

Inline

Sent from my iPhone

On Sep 19, 2015, at 3:07 PM, Christopher Ferris <chris.ferris(a)gmail.com> wrote:

Dmitri wrote: "When we do get to a point when it becomes a priority we will definitely share a proposal on bosh-notes with a community."

We aren't asking for giggles.

That quote is about *replacing* monit with something else, not about upgrading monit, which is what PR includes.

As Matt said, in comments, we are running into issues that need to be worked around. Hence, it is a priority for us, and likely for those who have submitted PRs and issues.

Well understood, so I'm asking for help to confirm in a real environment if monit 5.2.5 solves your problem. There is no way for us to know if new updates solve your problem and I'd like to avoid bumping this dependency without knowing that it will actually fix the problem. If you need help building a stemcell with updated monit, I can help with that.

AGPL can indeed be problematic, but I don't think we should discount it out of hand. The way monit is exposed and used in CF/BOSH with GPL was and is fine, so, copy-left isn't affecting the CF developed code/licensing. I suspect the same could be said for AGPL. Also, unless we or a user of BOSH changes the monit code, there's also no issue.

I suggest that we engage real lawyers to figure a way out of this issue; because as Matt has indicated, it is a problem/priority for some of us.

Matt has been trying to get the issue some attention. What do we need to do to get the priority discussion going in the BOSH PMC?

As mentioned in the thread once it's confirmed which version of monit resolves your problem (and hopefully doesn't introduce other problems) we can upgrade. If it's 5.2.5 great, if it's higher we'll have to involve CFF legal to give us thumbs up.

Thanks,

Chris

Sent from my iPhone

On Sep 19, 2015, at 3:11 PM, Dmitriy Kalinin <dkalinin(a)pivotal.io> wrote:

inline

Sent from my iPhone

On Sep 19, 2015, at 7:59 AM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote:

The monit used in the standard stem cells is ancient and there are two PRs to update it opened against bosh. I've been trying to understand what's going on by making comments on one of the PRs but I think a discussion would be easier here.

Can someone please explain why we a bump to monit 5.2.5 is not something that can just be done and tested through the existing bosh pipeline?

Existing bosh pipeline does very minimal testing of monit interoperability, partly because there is no dedicated test suite that test all kinds of cases. With changes that may affect all releases in unexpected ways, we typically try to get different teams to test the change before it's pulled into bosh. (Example: when we tried to properly wait for monit to stop, we didn't pull in that change because cf-release jobs started failing when nfs client was used. We will pull that change eventually when nfs is removed as a default from cf-release.)

It would be nice to have a test suite that just runs all kinds of releases against bosh for similar cases but we have not invested time in that yet.

What I suggested in one of the PR is for the team that's seeing an issue with monit 5.2.4 to build a stemcell with 5.2.5 and confirm that the issue is gone and doesn't cause any other side effects running in that environment. We don't see that issue in our environments so we cannot verify that bump would help. Since update to monit may introduce unrelated problems imho this is the quickest way to verify that bump is helpful.

Can someone please explain why moving beyond 5.2.5 is not possible? The only thing I've seen referenced is "license issues"; quite nebulous. I believe there was a move from GPLv3 to AGPL somewhere along the way but I'm not sure of the significance of that given how monit is used.

Agpl as I understand is on a lot of companies blacklists. If 5.2.5 update doesn't help the issue seen in that environment, we can spend time with CF Foundation figuring out if having monit being agpl is acceptable.

Finally, there were comments on PR #937 implying that Bosh wants to replace monit with something home grown. I have no issues with this but if it's going to be used as a reason not to stay current with software (the monit we're using is 4 years old), I feel like a proposal should at least be floated so outside contributors are aware. It's hard to help when the direction is not communicated.

Monit replacement ideas are just a hallway conversations.

We are not planning to replace monit any time soon due to other competing priorities like links, azs, stemcell hardening, backup, etc. When we do get to a point when it becomes a priority we will definitely share a proposal on bosh-notes with a community.

We are being conservative in how we bump monit since typically it affects all releases and figuring intricacies of monit especially when it's different versions is not a fun/productive activity.

Thanks.

--
Matthew Sykes
matthew.sykes(a)gmail.com