As a bosh user, I'd like to filter addon installation based on the type of a VM: errand, service, compilation

[voelzmo]

Some addons shouldn't be installed on certain types of VMs or should only be installed on certain types. So, in my runtime config and manifest filter for addon installation, I'd like to do this based on a VM's type. Types I'd like to distinguish: errand, service, compilation. Wdyt?

[pivotal-jamil-shamy]

@voelzmo interesting idea
One comment though: Maybe it can be renamed to be filter by instance type rather than VM type, so that it will not be mistaken for VM types defined in the cloud config(s), wdyt ?

[dpb587-pivotal]

Related: #1613

@voelzmo do you have an example of a release type which should be installed on compilation vms?

[cppforlife]

@voelzmo can you please add examples of each type of colocation you have in mind?

[voelzmo]

Ah, sorry, I completely missed this, thanks for the reminder.

• compilation VMs:
  • e.g. Virus scan. I only want virus scanning for sources and their dependencies, don't need Virus scanning during runtime (be is long-lived service or short-lived errands)
  • I'm also thinking about some license or CVE scan that could enforce that nobody installs stuff that doesn't match company policy. There are also other means to achieve this, if you e.g. limit the location from which you can install bosh-releases (i.e. only company-vetted releases are available)
• Service VMs:
  • Something like Turbulence or log-forwarding agents. I don't need those (or in a very different configuration) for compilation VMs or errands
• Errand VMs:
  • Not sure what those VMs specifically need. It seems to me, that they would not need most of the stuff I'd like to install on the other two types of VMs.

[voelzmo]

@cppforlife @dpb587-pivotal opinions about the use-cases?

[dpb587-pivotal]

The include-compilation use cases sound a bit weird - both of those use cases sound racy to me. There's no guarantee the addons may have finished scanning by the time compilation was finished. For completeness though, I think it might make sense regardless.

[voelzmo]

Ah, good point. I guess you’d also come up with cases where you want to exclude those scanning tools from compilation VMs then. I guess what I was looking for with the compilation cases above was something similar to multi buildpacks where I can include some scanning tool before my actual code is compiled. Thanks for the race condition reminder. On 21. Dec 2017, at 07:49, Danny Berger <notifications@github.com<mailto:notifications@github.com>> wrote: The include-compilation use cases sound a bit weird - both of those use cases sound racy to me. There's no guarantee the addons may have finished scanning by the time compilation was finished. For completeness though, I think it might make sense regardless. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1833 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACJv99sR5GMd7QE6Wv3XCADbTzALCoKmks5tCf-IgaJpZM4QbAio>.

[cppforlife]

story to address errands at least: https://www.pivotaltracker.com/story/show/155197799

[dpb587-pivotal]

Pull request for lifecycle filtering: #1902

[voelzmo]

Awesome, thanks! From: Danny Berger <notifications@github.com> Reply-To: cloudfoundry/bosh <reply@reply.github.com> Date: Thursday, 8. March 2018 at 21:29 To: cloudfoundry/bosh <bosh@noreply.github.com> Cc: "Voelz, Marco" <marco.voelz@sap.com>, Mention <mention@noreply.github.com> Subject: Re: [cloudfoundry/bosh] As a bosh user, I'd like to filter addon installation based on the type of a VM: errand, service, compilation (#1833) Pull request for lifecycle filtering: #1902<#1902> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1833 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACJv91E_OO2ELmJNq3h6dq7ReeCmIMO5ks5tcZSqgaJpZM4QbAio>.

[jfmyers9]

This has been implemented as of #1902