On 30.3.2017 17:39, Juan Antonio Osorio wrote:
Why not drive the post-config with something like shade over ansible?
Similar to what the kolla-ansible community is doing.
We could use those perhaps, if they bring enough benefit to add them to
the container image(s) (i think we'd still want to drive it via a
container rather than fully externally). It's quite tempting to just
load a yaml file with the endpoint definitions and just iterate over
them and let Ansible handle the actual API calls...
However, currently i can't see endpoint management in the cloud modules
docs [1], just service management. Looks like there's still a feature
gap at the moment.
Jirka
[1] http://docs.ansible.com/ansible/list_of_cloud_modules.html#openstack
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
