Open Stack

+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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180407/99b34c89/attachment.html>