Re: Droplets and Stacks
Thanks Onsi for these precisions.toggle quoted messageShow quoted text
Similar to Colin's blog question, I'm wondering how much versionning is
currently provided to rootfs and buildpacks. In other words, when a rootfs
(say cflinuxfs2) gets patched (e.g. following CVE such as in ), what
support is provided in the platform to identify apps that are still running
an old version of cflinuxfs2 rootfs and require restaging ?
Am I right to assume that there will be multiple distinct stack instances
returned by cc api calls such as  (with distinct guid but same entity
names) and that stacks are indeed immutable (i.e. the field "updated_at"
will remain null in  ) ? Writing a cli plugin to identify apps that need
restaging following a rootfs patch (similar to  but for a minor version
of a given stack), would therefore browse all stacks using , and order
those with the same name to understand minor patch version ?
I recall similar discussion related to buildpack versionning, where it was
mentionned that the buildpacks were mutable, and the only strategy to
support multiple versions of a buildpack is to append version numbers to
the buildpack names (and rely on priority ordering to have most recent
version be picked first). This has the drawback that an app specifying a
buildpack (e.g. to deambiguate or fix an invalid detect phase) will then
need to manually update the buildpack reference to benefit from new version
(a restaging won't be sufficient).
Is this correct ? On CF instances that don't version buildpack names, how
can users know whether apps were stage a vulrenable version of an offline
buildpack, and require restaging ? Is it by comparing staging date, and
known rootfs patch date ?
Is there some improvements planned around this stack and buildpack
versionning by the CAPI team (in tracker  seems related, is there
something more specific planned) ?
On Wed, Jul 29, 2015 at 7:16 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io> wrote: