Open Stack

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