Open Stack

Doug Hellmann wrote:
> Excerpts from Davanum Srinivas (dims)'s message of 2017-05-23 10:44:30 -0400:
>> For projects based on Go and Containers we need to ship binaries, for
> 
> Can you elaborate on the use of the term "need" here. Is that because
> otherwise the projects can't be consumed? Is it the "norm" for
> projects from those communities? Something else?

dims will likely answer directly, but I would say because it is the
"norm" there. If we were a Java project, we would definitely be
publishing JARs, for the exact same reason. Oh, wait. We actually do
Java stuff, so we ship JARs already:
http://tarballs.openstack.org/ci/monasca-common/

>> example Kubernetes, etcd both ship binaries and maintain stable
>> branches as well.
>>   https://github.com/kubernetes/kubernetes/releases
>>   https://github.com/coreos/etcd/releases/
>>
>> Kubernetes for example ships container images to public registeries as well:
>>   https://console.cloud.google.com/gcr/images/google-containers/GLOBAL/hyperkube?pli=1
>>   https://github.com/kubernetes/kubernetes/tree/master/cluster/images/hyperkube
> 
> What are the support lifetimes for those images? Who maintains them?

That's a good question. Due to various bundling and dependency
inclusion, security maintenance on those artifacts is definitely more
costly than our usual artifacts. Here by default I would say it's
probably best effort from the teams themselves.

That said, only a small fraction of our current OpenStack deliverables
are supported by the VMT and therefore properly security-maintained "by
the community" with strong guarantees and processes. So I don't see
adding such binary deliverables (maintained by their respective teams)
as a complete revolution. I'd expect the VMT to require a lot more
staffing (like dedicated people to track those deliverables content)
before they would consider those security-supported.

-- 
Thierry Carrez (ttx)