Open Stack

Dmitry,

>> 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?
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.

>> 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.

Thanks,

On Thu, Jan 29, 2015 at 12:06 AM, Dmitriy Shulyak <dshulyak at mirantis.com>
wrote:

>
> 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...
>
> __________________________________________________________________________
> 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/20150129/43a7acae/attachment.html>