<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">I also remember that Heat has smth like 'hidden' in resource plugin declaration. Usually it is used to hide deprecated resource types so that new stacks with those can not be created but old ones can be at least deleted. May be you could use that flag while developing until you think that resource is already usable, although it might complicate your own testing of those resources.</span></blockquote><div><br></div><div>In addition, I advice you to use UNSUPPORTED status untill resource will not be fully implemented. For details, suggest to read <a href="https://docs.openstack.org/developer/heat/developing_guides/supportstatus.html#life-cycle-of-resource-property-attribute">resource support status page</a>.</div><div class="gmail_extra"><br><div class="gmail_quote">2017-04-11 17:27 GMT+04:00 Pavlo Shchelokovskyy <span dir="ltr"><<a href="mailto:pshchelokovskyy@mirantis.com" target="_blank">pshchelokovskyy@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Norbert,<div><br></div><div>my biggest concern with the workflow you've shown is that in the meantime it would be possible to create undeletable stacks / stacks that leave resources behind after being deleted. As the biggest challenge is usually in updates (if it is not UpdateReplace) I'd suggest implementing create and delete together. To ease development you could start with only basic properties for the resource if it is possible to figure out their set (with some sane defaults if those are absent in API) and add more tunable resource properties later.</div><div><br></div><div>I also remember that Heat has smth like 'hidden' in resource plugin declaration. Usually it is used to hide deprecated resource types so that new stacks with those can not be created but old ones can be at least deleted. May be you could use that flag while developing until you think that resource is already usable, although it might complicate your own testing of those resources.</div><div><br></div><div>Cheers,</div></div><div class="gmail_extra"><br clear="all"><div><div class="m_-2825587464144865694gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Dr. Pavlo Shchelokovskyy<div>Senior Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Tue, Apr 11, 2017 at 3:33 PM, Norbert Illés <span dir="ltr"><<a href="mailto:norbert.e.illes@ericsson.com" target="_blank">norbert.e.illes@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
Me and two of my colleagues are working on adding Neutron Trunk support to Heat. One of us working on the resource implementation, one on the unit tests and one on the functional tests. But all of these looks like a big chunk of work so I'm wondering how can we divide them into smaller parts.<br>
<br>
One idea is to split them along life cycle methods (create, update, delete, etc.), for example:<br>
* Implement the resource creation + the relevant unit tests + the relevant functional tests, review and merge these<br>
* implementing the delete operation + the relevant unit tests + the relevant functional tests, review and merge these<br>
* move on to implementing the update operation + tests... and so on.<br>
<br>
Lastly, when the last part of the code and tests merged, we can document the new resource, create templates in the heat-templates etc.<br>
<br>
Is this workflow sounds feasible?<br>
<br>
I mostly concerned about the fact that there will be a time period when only a half-done feature merged into the Heat codebase, and I'm not sure if this is acceptable?<br>
<br>
Has anybody implemented a new resource with a team? I would love to hear some experiences about how others have organized this kind of work.<br>
<br>
Cheers,<br>
Norbert<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></div><br></div></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Best regards,<br></div>Peter Razumovsky<br></div></div>
</div></div>