Open Stack

Hi Dmitry,

I've read about inventories and I'm not sure if it's what we really need,
inventory provides you a way to have some kind of nodes discovery
mechanism, but what we need is to get some abstract data and convert
the data to more tasks friendly format.

In another thread I've mentioned Variables [1] in Ansible, probably it
fits more than inventory from architecture point of view.

With this functionality plugin will be able to get required information from
Nailgun via REST API and pass the information into specific task.

But it's not a way to go with the core deployment. I would like to remind
you what we had two years ago, we had Nailgun which passed the information
in format A to Orchestrator (Astute), than Orchestrator converted the
information
in second format B. It was horrible from debugging point of view, it's
always
hard when you have to go in several places to figure out what you get
as result. Your have pretty similar design suggestion, which is dividing
searilization logic between Nailgun and some another layer in tasks
scripts.

Thanks,

[1] http://docs.ansible.com/playbooks_variables.html#registered-variables

On Mon, Feb 2, 2015 at 5:05 PM, Dmitriy Shulyak <dshulyak at mirantis.com>
wrote:

>
> >> But why to add another interface when there is one already (rest api)?
>>
>> I'm ok if we decide to use REST API, but of course there is a problem
>> which
>> we should solve, like versioning, which is much harder to support, than
>> versioning
>> in core-serializers. Also do you have any ideas how it can be implemented?
>>
>
> We need to think about deployment serializers not as part of nailgun (fuel
> data inventory), but - part of another layer which uses nailgun api to
> generate deployment information. Lets take ansible for example, and
> dynamic inventory feature [1].
> Nailgun API can be used inside of ansible dynamic inventory to generate
> config that will be consumed by ansible during deployment.
>
> Such approach will have several benefits:
> - cleaner interface (ability to use ansible as main interface to control
> deployment and all its features)
> - deployment configuration will be tightly coupled with deployment code
> - no limitation on what sources to use for configuration, and how to
> compute additional values from requested data
>
> I want to emphasize that i am not considering ansible as solution for
> fuel, it serves only as example of architecture.
>
>
>> You run some code which get the information from api on the master node
>> and
>> then sets the information in tasks? Or you are going to run this code on
>> OpenStack
>> nodes? As you mentioned in case of tokens, you should get the token right
>> before
>> you really need it, because of expiring problem, but in this case you
>> don't
>> need any serializers, get required token right in the task.
>>
>
> I think all information should be fetched before deployment.
>
>>
>>
> >> What is your opinion about serializing additional information in
>> plugins code? How it can be done, without exposing db schema?
>>
>> With exposing the data in more abstract way the way it's done right now
>> for the current deployment logic.
>>
>
> I mean what if plugin will want to generate additional data, like -
> https://review.openstack.org/#/c/150782/? Schema will be still exposed?
>
> [1] http://docs.ansible.com/intro_dynamic_inventory.html
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150202/6fd93537/attachment.html>