Open Stack

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


In addition, I advice you to use UNSUPPORTED status untill resource will
not be fully implemented. For details, suggest to read resource support
status page
<https://docs.openstack.org/developer/heat/developing_guides/supportstatus.html#life-cycle-of-resource-property-attribute>
.

2017-04-11 17:27 GMT+04:00 Pavlo Shchelokovskyy <
pshchelokovskyy at mirantis.com>:

> Hi Norbert,
>
> 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.
>
> 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.
>
> Cheers,
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> On Tue, Apr 11, 2017 at 3:33 PM, Norbert Illés <
> norbert.e.illes at ericsson.com> wrote:
>
>> Hi everyone,
>>
>> 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.
>>
>> One idea is to split them along life cycle methods (create, update,
>> delete, etc.), for example:
>>  * Implement the resource creation + the relevant unit tests + the
>> relevant functional tests, review and merge these
>>  * implementing the delete operation + the relevant unit tests + the
>> relevant functional tests, review and merge these
>>  * move on to implementing the update operation + tests... and so on.
>>
>> Lastly, when the last part of the code and tests merged, we can document
>> the new resource, create templates in the heat-templates etc.
>>
>> Is this workflow sounds feasible?
>>
>> 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?
>>
>> 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.
>>
>> Cheers,
>> Norbert
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> 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
>
>


-- 
Best regards,
Peter Razumovsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170412/3691bfa9/attachment.html>