Its a standard way of launching a given openstack service container with specified config regardless if its backed with a redhat or ubuntu or source based package set that the Operator can rely on having a standardized interface to. distro packages don't grantee that kind of thing and don't want to.
To me, its an abstraction api kind of like nova is to kvm vs xen. the nova user shouldn't have to care which backend is chosen. Thanks, Kevin ________________________________________ From: Jay Pipes [jaypi...@gmail.com] Sent: Wednesday, July 27, 2016 2:12 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off On 07/27/2016 04:42 PM, Ed Leafe wrote: > On Jul 27, 2016, at 2:42 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > >> Its not an "end user" facing thing, but it is an "operator" facing thing. > > Well, the end user for Kolla is an operator, no? > >> I deploy kolla containers today on non kolla managed systems in production, >> and rely on that api being consistent. >> >> I'm positive I'm not the only operator doing this either. This sounds like a >> consumable api to me. > > I don’t think that an API has to be RESTful to be considered an interface for > we should avoid duplication. Application *Programming* Interface. There's nothing that is being *programmed* or *called* in Kolla's image definitions. What Kolla is/has is not an API. As Stephen said, it's more of an Application Binary Interface (ABI). It's not really an ABI, though, in the traditional sense of the term that I'm used to. It's an agreed set of package bases, installation procedures/directories and configuration recipes for OpenStack and infrastructure components. I see no reason for the OpenStack community to standardize on those things, frankly. It's like asking RedHat and Canonical to agree to "just use RPM" as their package specification format. I wonder how that conversation would go. Best, -jay __________________________________________________________________________ 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
