> >> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
