Open Stack

Sorry for the double post, but the part about people wasting their time 
reads far more inflammatory than I really intended. I merely mean 
community effort is a strong theme.


On 7/28/2016 11:20 AM, Mark Casey wrote:
>
> +1 to one more pass at using the same images. Doing so will become 
> practically impossible in a matter of weeks or months, and in the long 
> term the additional shared human resources outweigh the interpersonal 
> complexities (and for any who don't think so - maybe you're wasting 
> your time here?).
>
>
> Logically, I just view Kolla's existing containers as a thin wrapper 
> around OpenStack projects' debs and rpms (though I understand there 
> are many differences from a purely technical standpoint, and that the 
> containers can be built entirely from source instead). I suppose I 
> view them this way because building the existing containers creates 
> deployable artifacts (that is, the images) and these images have a lot 
> of the same qualities as traditional deb/rpm packages. The resulting 
> artifacts in both cases are somewhat immutable, they both put programs 
> in certain places, both expect configs in certain places, both 
> configure logs to be written in certain places, etc. In fact a lot of 
> these locations in the container's case are dictated by where they are 
> expected in the packages. Sharing the images could further standardize 
> things.
>
>
> This is different IMHO than deployment tooling in the usual 
> configuration management sense, which I presume is one of the reasons 
> for this possible Kolla repo-split to begin with. I certainly see the 
> upsides to having a diverse set of tooling to deploy project artifacts 
> (deb/rpm/container image/git commit [i.e. from source]), but I don't 
> get duplicating the artifacts themselves over relatively simple 
> technicalities. I highly doubt anyone would create a major packaging 
> variation in the deb/rpm packaging (perhaps where all OpenStack 
> projects are deployable from a single rpm or deb [wouldn't that be 
> fun!], or perhaps a switch to FPM) merely because it made sense for a 
> new deployment project. (to be clear though, I am in general happy to 
> have more deployment options coming online)
>
>
> Thank you,
> Mark
>
>
> On 7/28/2016 8:56 AM, Fox, Kevin M wrote:
>> I really see 3 issues raised in the spec mentioned that have any 
>> disagreement as far as I can tell.
>>
>> 1. mirantis would like to see kolla-ansible split from the base kolla 
>> repo. This has a lot of support and is likely to come up for a final 
>> vote soon. It was postponed due to not wanting to split in the middle 
>> of a cycle. - This does not seem like a good reason at this point to 
>> spawn a new project. I support the split.
>>
>> 2. mirantis would like to see repos split for each docker container 
>> definition to be one per container. This is purely a management style 
>> difference. Split or combined both has advantages, and at present 
>> scaling issues have not been hit, so change has a cost that doesn't 
>> yet have a significant benefit. If it started to be, I'm sure it 
>> would be re-evaluated. This does not seem like a good reason at this 
>> point to spawn a new project. I think splitting seems unnecessary at 
>> this point, but if the whole thing comes down to this one issue, I'd 
>> support splitting the repos just so we don't duplicate so much work 
>> over such a minor thing.
>>
>> 3. Some bootstrap logic in some of the containers. mirantis would 
>> like to see it gone. Its completely optional (just don't set the 
>> BOOTSTRAP env vars) and needs to stay for api backwards compatibility 
>> in existing containers. It does not have to be used by deployment 
>> tools that don't wish to use it. This does not seem like a good 
>> reason at this point to spawn a new project. I support keeping it to 
>> not break things as its optional.
>>
>> Are these really that contentious that we have to split a community 
>> over? Can we get both sides to give in a little and help each other out?
>>
>> Maybe something like:
>> 1. kolla commits to split out kolla-ansible as soon as possible 
>> (right after newton tagged)
>> 2. Some middle ground here. Maybe its keep as is, but come up with a 
>> formal procedure for re-evaluating when it becomes painful and make a 
>> change. (Seems similar to the fuel/puppet repo upstreaming thing, in 
>> a way. Maybe some of the same process could work here? Some time to 
>> review metrics?)
>> 3. We keep the optional stuff so we don't break existing deployments.
>>
>> Is this reasonable?
>>
>> Thanks,
>> Kevin
>> ------------------------------------------------------------------------
>> *From:* Vladimir Kozhukalov [vkozhukalov at mirantis.com]
>> *Sent:* Thursday, July 28, 2016 5:48 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like 
>> Mirantis is getting Fuel CCP (docker/k8s) kicked off
>>
>> >1. Alter the mission statement of fuel to match the reality being
>>
>> >published by the press and Mirantis's executive team
>>
>> >2. Include these non-experimental repos in the projects.yaml governance
>>
>> >Repository
>>
>>
>> Frankly, I don’t understand what part of the press release 
>> contradicts with Fuel mission.
>>
>> Current Fuel mission is “To streamline and accelerate the process of 
>> deploying, testing and maintaining various configurations of 
>> OpenStack at scale.” which means we are not bound to any specific 
>> technology when deploying OpenStack.
>>
>>
>> At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel 
>> specific orchestration mechanism. We are not going to drop this 
>> approach immediately, it works quite well and we are working hard to 
>> make things better (including ability to upgrade). But we also keep 
>> in mind that technologies are constantly changing and we’d like to 
>> benefit of this progress. That is why we are now looking at Docker 
>> containers and Kubernetes. Our users know that it is not our first 
>> experience of trying to use containers. Fuel releases prior to 9.0 
>> used to deploy Fuel services in containers on the Fuel admin node.
>>
>>
>> Many of you know how difficult it is to upgrade OpenStack clusters. 
>> We hope that containers could help us to solve not all but some of 
>> problems that we encounter when upgrading cluster. Maintaining and 
>> hence upgrade of OpenStack clusters is a part of Fuel mission and we 
>> are just trying to find a way how to do things.
>>
>>
>> Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by 
>> Mirantis. At Mirantis we deploy and maintain OpenStack. In attempts 
>> to find a way how to make OpenStack easily maintainable, some of 
>> Mirantis folks spent some time to contribute to Kolla and Mesos. But 
>> there were some concerns that were discussed several times (including 
>> this Kolla spec https://review.openstack.org/#/c/330575) that would 
>> make it not so easy to use Kolla containers for our use cases. 
>> Fuel-ccp is just an attempt to address these concerns. Frankly, I 
>> don’t see anything bad in having more than one set of container 
>> images (like we have more than one set of RPM/DEB distributions).
>>
>>
>> Those concerns are, for example, container images should not be bound 
>> to any specific deployment technology. Containers in some sense are a 
>> similar concept to RPM/DEB packages and it does not matter what 
>> deployment tool (puppet, ansible) one uses to install them. There 
>> should be mature CI pipeline for building/testing/publishing images. 
>> There should be a convenient way (kind of DSL) to deal with dozens of 
>> images. I’d like to avoid discussing this here once again.
>>
>>
>> Fuel-ccp repositories are public, everyone is welcome to participate. 
>> I don’t see where we violate “4 opens”. These repos are now 
>> experimental. At the moment the team is working on building CI 
>> pipeline and developing functional tests that are to be run as a part 
>> of CI process. These repos are not to be a part of Fuel Newton 
>> release. From time to time we add and retire git repos and it is a 
>> part of development process. Not all these repos are to become a part 
>> of Big tent.
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Jul 28, 2016 at 7:45 AM, Steven Dake (stdake) 
>> <stdake at cisco.com <mailto:stdake at cisco.com>> wrote:
>>
>>
>>
>>     On 7/27/16, 2:12 PM, "Jay Pipes" <jaypipes at gmail.com
>>     <mailto:jaypipes at gmail.com>> wrote:
>>
>>     >On 07/27/2016 04:42 PM, Ed Leafe wrote:
>>     >> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov
>>     <mailto:Kevin.Fox at 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.
>>
>>     Jay,
>>
>>     From my perspective, this isn't about ABI proliferation or
>>     competition.
>>     This is about open public discourse.
>>
>>     It is the responsibility of all community members to protect the four
>>     opens.
>>
>>     Given the intent of fuel-ccp to fully adopt K8S into Fuel
>>     described here:
>>     https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top
>>     -of-kubernetes/
>>     <https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top%0A-of-kubernetes/>
>>
>>
>>     It is hard to understand the arguments in the reviews related to
>>     "this is
>>     an experimental project, so its not targeted towards big tent"
>>     yet Boris
>>     wrote in that press release its Fuel's next big thing.
>>
>>     I raised the objection early on that a mission statement change
>>     was needed
>>     by Fuel if they wanted to proceed down this path, to which I was
>>     told K8S
>>     support is not going into big tent.
>>
>>     As a result of Mirantis's change in mind about fuel-ccp being NOT
>>     experimental and being targeted for big tent, I'd like the record set
>>     straight in the governance repository since the intentions are being
>>     published in the press and the current intentions of this project are
>>     public.
>>
>>     I could see how people could perceive many violations of the four
>>     opens in
>>     all of the activities related to the fuel-ccp project.  We as a
>>     community
>>     value open discourse because we are all intelligent human beings.  We
>>     value honesty and integrity because trust is the foundation of
>>     how our
>>     community operates.  I feel the best way for Fuel to repair the
>>     perceived
>>     violations of the four opens going forward is to:
>>
>>     1. Alter the mission statement of fuel to match the reality being
>>     published by the press and Mirantis's executive team
>>     2. Include these non-experimental repos in the projects.yaml
>>     governance
>>     repository
>>
>>     That would satisfy my four opens concerns.
>>
>>     If the Fuel PTL doesn't want to do these two things, I'd like a
>>     public
>>     explanation as to why from Vladimir who thus far has remained
>>     quiet on
>>     this thread.
>>
>>     Thanks
>>     -steve
>>
>>
>>
>>
>>     >
>>     >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-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160728/2c3bf898/attachment.html>