[openstack-dev] [Fuel] Cluster replaced deployment of provisioning information
vkuklin at mirantis.com
Thu Jan 29 09:04:47 UTC 2015
I would just like to point out that we will certainly need to consume
resources from 3rd party sources also. We also want to remove any specific
data manipulation from puppet code. Please, consider these use cases also.
On Thu, Jan 29, 2015 at 12:06 AM, Dmitriy Shulyak <dshulyak at mirantis.com>
> 1. as I mentioned above, we should have an interface, and if interface
>> 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
>> 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
> 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
Fuel Library Tech Lead,
+7 (495) 640-49-04
+7 (926) 702-39-68
45bk3, Vorontsovskaya Str.
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev