[snip]
>> 4) <deployable-xml>
>>
>> *Should we wrap the deployable template into CDATA or not?* The benefit is that
the inner XML will not be parsed by the client when parsing the API response, so an error
in the template XML can't break the whole API response. And it is semantically
cleaner, because the template XML won't be part of the API response XML tree, but will
be treated as data, which it is. (Think if we provided JSON API, then the template XML
would be treated as a data too and not converted into a corresponding JSON structure,
I'd say.) The drawback is that our deployable then can't have a CDATA in it,
because CDATA nesting is not allowed. For deployable templates, this might not be a
problem right now, but I wonder about the future. E.g. for image templates it would be a
problem [3]. So I'm sort of on the fence here, maybe a bit in favour of not wrapping
it into CDATA. (Btw Tim solves this by having image template as a separate resource, but
I'm not sure we should go this way for deployables a!
s!
we!
>> ll.)
>
> I would vote for a separate resource. There is xml embedded in the instance resource
too, and this sounds like the cleanest way around it.
To brainstorm further - if we make it a separate resource, I wonder if we should make it
totally separate, like Tim has it (template can be created independently of images). Say:
/api/deployabletemplates/:id
Then deployables and deployments DB records would link to these templates, and templates
would have to become read-only (create, but never update), like in Tim.
This would force us to do significant changes in the DB model as well (and I wonder if
we'd want/need to change UI workflow anyhow), because currently the template is
embedded as an attribute into deployable and deployment. This solution would be probably
very time consuming to implement, but should be possible.
Or, if we should make it as a simple nested subresource. Say:
/api/deployables/:deployable_id/template
/api/deployment/:deployment_id/template
This approaich is imho possible without performing a major surgery on Conductor and
solves the problem of API representation. The first approach on the other hand seems a bit
cleaner by design.
I cannot decide right now which one I'd prefer more :)
This thread got somehow forgotten :) Mainn actually just pinged me about Conductor +
Winged Monkey and we found out that we need to have this decided.
1) Deployable XMLs
So do you guys think it is desirable to model deployable XMLs like this:
<deployment id='1' href='.../api/deployments/1'>
<deployable_template
href=".../api/deployments/1/deployable_template"/>
</deployment>
or should we embed them into <deployment> as <deployable_xml>?
^^ This issue touches also instances API and deployables API. I don't have a sharp
opinion here, but I'd like to make sure that we come up with something consistent in
our pull requests and not different solutions per author :)
2) States
Can I assume that printing state of deployments/deployables this way is correct?
<deployment>
<state>running</state>
</deployment>
Right now I don't need decision about starting/stopping instances, just want to assert
that this is the way we'll be printing states. I'd like to have deployment GET
ready for Mainn this sprint with all info he needs.
Thanks :)
J.