On Sat, Apr 7, 2018 at 11:11 AM, Jeffrey Zhang <zhang.lei....@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) <std...@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 <m...@stackhpc.com> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: Friday, April 6, 2018 at 12:30 PM >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@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.an...@redhat.com> wrote: >> >> On Thu, Apr 5, 2018 at 2:16 PM, Paul Bourke <paul.bou...@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-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 >> >> >> __________________________________________________________________________ >> 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 >> > > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __________________________________________________________________________ > 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
