Open Stack

> 1. as I mentioned above, we should have an interface, and if interface
> doesn't
>     provide required information, you will have to fix it in two places,
>     in Nailgun and in external-serializers, instead of a single place i.e.
> in Nailgun,
>     another thing if astute.yaml is a bad interface and we should provide
> another
>     versioned interface, or add more data into deployment serializer.
>
But why to add another interface when there is one already (rest api)? And
plugin developer
may query whatever he want (detailed information about volumes, interfaces,
master node settings).
It is most full source of information in fuel and it is already needs to be
protected from incompatible changes.

If our API will be not enough for general use - ofcourse we will need to
fix it, but i dont quite understand what do
you mean by - fix it in two places. API provides general information that
can be consumed by serializers (or any other service/human actually),
and if there is some issues with that information - API should be fixed.
Serializers expects that information in specific format and makes
additional transformation or computation based on that info.

What is your opinion about serializing additional information in plugins
code? How it can be done, without exposing db schema?

2. it can be handled in python or any other code (which can be wrapped into
> tasks),
>     why should we implement here another entity (a.k.a external
> serializers)?
>
Yep, i guess this is true, i thought that we may not want to deliver
credentials to the target nodes, and only token that can be used
for limited time, but...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150128/0a7cc1f7/attachment.html>