On 16.05.2017 20:57, Michał Jastrzębski wrote: > On 16 May 2017 at 11:49, Doug Hellmann <d...@doughellmann.com> wrote: >> Excerpts from Michał Jastrzębski's message of 2017-05-16 11:38:19 -0700: >>> On 16 May 2017 at 11:27, Doug Hellmann <d...@doughellmann.com> wrote: >>>> Excerpts from Michał Jastrzębski's message of 2017-05-16 09:46:19 -0700: >>>>> So another consideration. Do you think whole rule of "not building >>>>> binares" should be reconsidered? We are kind of new use case here. We >>>>> aren't distro but we are packagers (kind of). I don't think putting us >>>>> on equal footing as Red Hat, Canonical or other companies is correct >>>>> here. >>>>> >>>>> K8s is something we want to work with, and what we are discussing is >>>>> central to how k8s is used. K8s community creates this culture of >>>>> "organic packages" built by anyone, most of companies/projects already >>>>> have semi-official container images and I think expectations on >>>>> quality of these are well...none? You get what you're given and if you >>>>> don't agree, there is always way to reproduce this yourself. >>>>> >>>>> [Another huge snip] >>>>> >>>> >>>> I wanted to have the discussion, but my position for now is that >>>> we should continue as we have been and not change the policy. >>>> >>>> I don't have a problem with any individual or group of individuals >>>> publishing their own organic packages. The issue I have is with >>>> making sure it is clear those *are* "organic" and not officially >>>> supported by the broader community. One way to do that is to say >>>> they need to be built somewhere other than on our shared infrastructure. >>>> There may be other ways, though, so I'm looking for input on that. >>> >>> What I was trying to say here is, current discussion aside, maybe we >>> should revise this "not supported by broader community" rule. They may >>> very well be supported to a certain point. Support is not just yes or >>> no, it's all the levels in between. I think we can afford *some* level >>> of official support, even if that some level means best effort made by >>> community. If Kolla community, not an individual like myself, would >>> like to support these images best to our ability, why aren't we >>> allowed? As long as we are crystal clear what is scope of our support, >>> why can't we do it? I think we've already proven that it's going to be >>> tremendously useful for a lot of people, even in a shape we discuss >>> today, that is "best effort, you still need to validate it for >>> yourself"... >> >> Right, I understood that. So far I haven't heard anything to change >> my mind, though. >> >> I think you're underestimating the amount of risk you're taking on >> for yourselves and by extension the rest of the community, and >> introducing to potential consumers of the images, by promising to >> support production deployments with a small team of people without >> the economic structure in place to sustain the work. > > Again, we tell what it is and what it is not. I think support is > loaded term here. Instead we can create lengthy documentation > explaining to a detail lifecycle and testing certain container had to > pass before it lands in dockerhub. Maybe add link to particular set of > jobs that container had passed. Only thing we can offer is automated > and transparent process of publishing. On top of that? You are on your > own. But even within these boundaries, a lot of people could have > better experience of running OpenStack...
That totally makes sense. Supporting builds like "a published container passed some test scenarios for our CI gates, here is a link to particular set of jobs that container had passed" benefits all and has nothing to the production use cases and guarantees nothing in terms of supporting them. > >> Doug >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev