Open Stack

On Sat, Apr 7, 2018 at 11:11 AM, Jeffrey Zhang <zhang.lei.fly at gmail.com> wrote:
> +1 for kolla-api
>
> Migrate all scripts from kolla(image) to kolla-ansible, will make image hard
> to use by
> downstream. Martin explain this clearly. we need some API to make images
> more easy to use.
> For the operator, I don't think he needs to read all the set_config.py file.
> Just knowing
> how the config.json file looks like and effects of the file are enough. So a
> doc is enough.
>

Yes agree, moving the scripts from kolla will not be that soft to use
for downstream.
And it seems very reasonable to me that kolla API can be a good thing
to make images easy to use

>
> For images, we need to add some common functions before using them. Instead
> of
> using the upstream image directly. For example, if we support loci, mostly
> we
> will use upgrade infra images. like mariadb, redis etc. But is them really
> enough
> for production use directly? there is some concern here
>
> - drop root. does it work when it runs without root?
> - init process. Does it contain a init process binary?
> - configuration. The different image may use different configuration method.
> Should we need
>   unify them?
> - lack of packages. what the image lack some packages we needed?
>
>
> One of a possible solution for this, I think, is use upstream image +
> kolla-api to generate a
> image with the features.
>
> On Sat, Apr 7, 2018 at 6:47 AM, Steven Dake (stdake) <stdake at cisco.com>
> wrote:
>>
>> Mark,
>>
>>
>>
>> TLDR good proposal
>>
>>
>>
>> I don’t think Paul was proposing what you proposed.  However:
>>
>>
>>
>> You make a strong case for separately packaging the api (mostly which Is
>> setcfg.py and the json API + docs + samples).  I am super surprised nobody
>> has ever proposed this in the past, but now is as good of a time as any to
>> propose a good model for managing the JSON->setcfg.py API.  We could unit
>> test this with extreme clarity, document with extreme clarity, and provide
>> an easier path for people to submit changes to the API that they require to
>> run the OpenStack containers.  Finally, it would provide complete semver
>> semantics for managing change and provide perfect backwards compatibility.
>>
>>
>>
>> A separate repo for this proposed api split makes sense to me.  I think
>> initially we would want to seed with the kolla core team but be open to
>> anyone that reviews + contributes to join the kolla-api core team (just as
>> happens with other kolla deliverables).
>>
>>
>>
>> This should reduce cross-project developer friction which was an implied
>> but unstated problem in the various threads over the last week and produce
>> the many other beneficial effects APIs produce along with the benefits you
>> stated above.
>>
>>
>>
>> I’m not sure if this approach is technically sound –but I’d be in favor of
>> this approach if it were not too disruptive, provided full backwards
>> compatibility and was felt to be an improvement by the consumers of kolla
>> images.  I don’t think deprecation is something that is all that viable with
>> an API model like the one we have nor this new repo and think we need to set
>> clear boundaries around what would/would not be done.
>>
>>
>>
>> I do know that a change of this magnitude is a lot of work for the
>> community to take on – and just like adding or removing any deliverable in
>> kolla, would require a majority vote from the CR team.
>>
>>
>>
>> Also, repeating myself, I don’t think the current API is good nor perfect,
>> I don’t think perfection is necessarily possible, but this may help drive
>> towards that mythical perfection that interested parties seek to achieve.
>>
>>
>> Cheers
>>
>> -steve
>>
>>
>>
>> From: Mark Goddard <mark at stackhpc.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Date: Friday, April 6, 2018 at 12:30 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [kolla] [tripleo] On moving start scripts out
>> of Kolla images
>>
>>
>>
>>
>>
>> On Thu, 5 Apr 2018, 20:28 Martin André, <m.andre at redhat.com> wrote:
>>
>> On Thu, Apr 5, 2018 at 2:16 PM, Paul Bourke <paul.bourke at oracle.com>
>> wrote:
>> > Hi all,
>> >
>> > This mail is to serve as a follow on to the discussion during
>> > yesterday's
>> > team meeting[4], which was regarding the desire to move start scripts
>> > out of
>> > the kolla images [0]. There's a few factors at play, and it may well be
>> > best
>> > left to discuss in person at the summit in May, but hopefully we can get
>> > at
>> > least some of this hashed out before then.
>> >
>> > I'll start by summarising why I think this is a good idea, and then
>> > attempt
>> > to address some of the concerns that have come up since.
>> >
>> > First off, to be frank, this is effort is driven by wanting to add
>> > support
>> > for loci images[1] in kolla-ansible. I think it would be unreasonable
>> > for
>> > anyone to argue this is a bad objective to have, loci images have very
>> > obvious benefits over what we have in Kolla today. I'm not looking to
>> > drop
>> > support for Kolla images at all, I simply want to continue decoupling
>> > things
>> > to the point where operators can pick and choose what works best for
>> > them.
>> > Stemming from this, I think moving these scripts out of the images
>> > provides
>> > a clear benefit to our consumers, both users of kolla and third parties
>> > such
>> > as triple-o. Let me explain why.
>>
>> It's still very obscure to me how removing the scripts from kolla
>> images will benefit consumers. If the reason is that you want to
>> re-use them in other, non-kolla images, I believe we should package
>> the scripts. I've left some comments in your spec review.
>>
>>
>>
>> +1 to extracting and packaging the kolla API. This will make it easier to
>> test and document, allow for versioning, and make it a first class citizen
>> rather than a file in the build context of the base image. Plus, if it
>> really is as good as some people are arguing, then it should be shared.
>>
>>
>>
>> For many of the other helper scripts that get bundled into the kolla
>> images, I can see an argument for pulling these up to the deployment layer.
>> These could easily be moved to kolla-ansible, and added via config.json. I
>> guess it would be useful to know whether other deployment tools (tripleo)
>> are using any of these - if they are shared then perhaps the images are the
>> best place for them.
>>
>>
>>
>>
>> > Normally, to run a docker image, a user will do 'docker run
>> > helloworld:latest'. In any non trivial application, config needs to be
>> > provided. In the vast majority of cases this is either provided via a
>> > bind
>> > mount (docker run -v hello.conf:/etc/hello.conf helloworld:latest), or
>> > via
>> > environment variables (docker run --env HELLO=paul helloworld:latest).
>> > This
>> > is all bog standard stuff, something anyone who's spent an hour learning
>> > docker can understand.
>> >
>> > Now, lets say someone wants to try out OpenStack with Docker, and they
>> > look
>> > at Kolla. First off they have to look at something called
>> > set_configs.py[2]
>> > - over 400 lines of Python. Next they need to understand what that
>> > script
>> > consumes, config.json [3]. The only reference for config.json is the
>> > files
>> > that live in kolla-ansible, a mass of jinja and assumptions about how
>> > the
>> > service will be run. Next, they need to figure out how to bind mount the
>> > config files and config.json into the container in a way that can be
>> > consumed by set_configs.py (which by the way, requires the base kolla
>> > image
>> > in all cases). This is only for the config. For the service start up
>> > command, this need to also be provided in config.json. This command is
>> > then
>> > parsed out and written to a location in the image, which is consumed by
>> > a
>> > series of start/extend start shell scripts. Kolla is *unique* in this
>> > regard, no other project in the container world is interfacing with
>> > images
>> > in this way. Being a snowflake in this regard is not a good thing. I'm
>> > still
>> > waiting to hear from a real world operator who would prefer to spend
>> > time
>> > learning the above to doing:
>>
>> You're pointing a very real documentation issue. I've mentioned in the
>> other kolla thread that I have a stub for the kolla API documentation.
>> I'll push a patch for what I have and we can iterate on that.
>>
>> >   docker run -v /etc/keystone:/etc/keystone keystone:latest --entrypoint
>> > /usr/bin/keystone [args]
>> >
>> > This is the Docker API, it's easy to understand and pretty much the
>> > standard
>> > at this point.
>>
>> Sure, using the docker API works for simpler cases, not too
>> surprisingly once you start doing more funky things with your
>> containers you're quickly reach the docker API limitations. That's
>> when the kolla API comes in handy.
>> See for example this recent patch
>> https://review.openstack.org/#/c/556673/ where we needed to change
>> some file permission to the uid/gid of the user inside the container.
>>
>> The first iteration basically used the docker API and started an
>> additional container to fix the permissions:
>>
>>   docker run -v
>> /etc/pki/tls/certs/neutron.crt:/etc/pki/tls/certs/neutron.crt:rw \
>>         -v
>> /etc/pki/tls/private/neutron.key:/etc/pki/tls/private/neutron.key:rw
>> \
>>         neutron_image \
>>         /bin/bash -c 'chown neutron:neutron
>> /etc/pki/tls/certs/neutron.crt; chown neutron:neutron
>> /etc/pki/tls/private/neutron.key'
>>
>> You'll agree this is not the most obvious. And it had a nasty side
>> effect that is changes the permissions of the files _on the host_.
>> While using kolla API we could simply add to our config.json:
>>
>>   - path: /etc/pki/tls/certs/neutron.crt
>>     owner: neutron:neutron
>>   - path: /etc/pki/tls/private/neutron.key
>>     owner: neutron:neutron
>>
>> > The other argument is that this removes the possibility for immutable
>> > infrastructure. The concern is, with the new approach, a rookie operator
>> > will modify one of the start scripts - resulting in uncertainty that
>> > what
>> > was first deployed matches what is currently running. But with the way
>> > Kolla
>> > is now, an operator can still do this! They can restart containers with
>> > a
>> > custom entrypoint or additional bind mounts, they can exec in and change
>> > config files, etc. etc. Kolla containers have never been immutable and
>> > we're
>> > bending over backwards to artificially try and make this the case. We
>> > cant
>> > protect a bad or inexperienced operator from shooting themselves in the
>> > foot, there are better ways of doing so. If/when Docker or the upstream
>> > container world solves this problem, it would then make sense for Kolla
>> > to
>> > follow suit.
>> >
>> > On the face of it, what the spec proposes is a simple change, it should
>> > not
>> > radically pull the carpet out under people, or even change the way
>> > kolla-ansible works in the near term. If consumers such as tripleo or
>> > other
>> > parties feel it would in fact do so please do let me know and we can
>> > discuss
>> > and mitigate these problems.
>>
>> TripleO uses these scripts extensively, we certainly do not want to
>> see them go away from kolla images.
>>
>> Martin
>>
>> > Cheers,
>> > -Paul
>> >
>> > [0] https://review.openstack.org/#/c/550958/
>> > [1] https://github.com/openstack/loci
>> > [2]
>> >
>> > https://github.com/openstack/kolla/blob/master/docker/base/set_configs.py
>> > [3]
>> >
>> > https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/keystone/templates/keystone.json.j2
>> > [4]
>> >
>> > http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-04-04-16.00.log.txt
>> >
>> >
>> > __________________________________________________________________________
>> > 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
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __________________________________________________________________________
> 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
>