Why not drive the post-config with something like shade over ansible? Similar to what the kolla-ansible community is doing.
On 30 Mar 2017 16:42, "Jiří Stránský" <[email protected]> wrote: > On 30.3.2017 14:58, Dan Prince wrote: > >> There is one case that I was thinking about reusing this piece of code >> within a container to help initialize keystone endpoints. It would >> require some changes and updates (to match how puppet-* configures >> endpoints). >> >> For TripleO containers we use various puppet modules (along with hiera) >> to drive the creation of endpoints. This functionally works fine, but >> is quite slow to execute (puppet is slow here) and takes several >> minutes to complete. I'm wondering if a single optimized python script >> might serve us better here. It could be driven via YAML (perhaps >> similar to our Hiera), idempotent, and likely much faster than having >> the code driven by puppet. This doesn't have to live in os-cloud- >> config, but initially I thought that might be a reasonable place for >> it. It is worth pointing out that this would be something that would >> need to be driven by our t-h-t workflow and not a post-installation >> task. So perhaps that makes it not a good fit for os-cloud-config. But >> it is similar to the keystone initialization already there so I thought >> I'd mention it. >> > > I agree we could have an optimized python script instead of puppet to do > the init. However, os-cloud-config also doesn't strike me as the ideal > place. > > What might be interesting is solving the keystone init within containers > along with our container entrypoint situation. We've talked earlier that we > may have to build our custom entrypoints into the images as we sometimes > need to do things that the current entrypoints don't seem fit for, or don't > give us enough control over what happens. This single optimized python > script for endpoint config you mentioned could be one of such in-image > entrypoint scripts. We could build multiple different scripts like this > into a single image and select the right one when starting the container > (defaulting to a script that handles the usual "worker" case, in this case > Keystone API). > > This gets somewhat similar to the os-cloud-config usecase, but even if we > wanted a separate repo, or even a RPM for these, i suppose it would be > cleaner to just start from scratch rather than repurpose os-cloud-config. > > Jirka > > >> Dan >> >> On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote: >> >>> Hi, >>> >>> os-cloud-config was deprecated in the Ocata release and is going to >>> be >>> removed in Pike. >>> >>> TripleO project doesn't need it anymore and after some investigation >>> in codesearch.openstack.org, nobody is using it in OpenStack. >>> I'm working on the removal this cycle, please let us know any >>> concern. >>> >>> Thanks, >>> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
