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
Hi Dmitry,
I've read about inventories and I'm not sure if it's what we really need,
inventory provides you a way to have some kind of nodes discovery
mechanism, but what we need is to get some abstract data and convert
the data to more tasks friendly format.
In another thread I've mentioned
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
Guys
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 dshul...@mirantis.com
It's not clear what problem you are going to solve with putting serializers
alongside with deployment scripts/tasks.
I see two possible uses for specific serializer for tasks:
1. Compute additional information for deployment based not only on what is
present in astute.yaml
2. Request
Hi Vladimir,
It's not clear what problem you are going to solve with putting serializers
alongside with deployment scripts/tasks.
For sure there is no way for this serializers to have access to the
database,
because with each release there will be a huge probability to get this
serializers broken
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
Hi Dmitry!
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
Dmitry
This is an interesting topic. As per our discussions earlier, I suggest
that in the future we move to different serializers for each granule of our
deployment, so that we do not need to drag a lot of senseless data into
particular task being executed. Say, we have a fencing task, which has
On Thu, Jan 22, 2015 at 7:59 PM, Evgeniy L e...@mirantis.com wrote:
The problem with merging is usually it's not clear how system performs
merging.
For example you have the next hash {'list': [{'k': 1}, {'k': 2}, {'k':
3}]}, and I want
{'list': [{'k': 4}]} to be merged, what system should
On Tue, Jan 27, 2015 at 10:47 AM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
This is an interesting topic. As per our discussions earlier, I suggest
that in the future we move to different serializers for each granule of our
deployment, so that we do not need to drag a lot of senseless data
Hi Dmitry,
The problem with merging is usually it's not clear how system performs
merging.
For example you have the next hash {'list': [{'k': 1}, {'k': 2}, {'k':
3}]}, and I want
{'list': [{'k': 4}]} to be merged, what system should do? Replace the list
or add {'k': 4}?
Both cases should be
12 matches
Mail list logo
