Hi,

Thanks for the advices! The HIDDEN status looks better for me as it completely hides the resource from the user and it won't be included in the documentation, but using this to status to mark the implementation of the resource incomplete feels like a misuse of this status.

So I believe, we should use the UNSUPPORTED attribute in this case
and implement the create and delete operations together + the relevant test then the update + the relevant test.

Cheers,
Norbert

On 04/12/2017 12:26 PM, Peter Razumovsky wrote:
    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
<pshchelokovs...@mirantis.com <mailto:pshchelokovs...@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 <http://www.mirantis.com>

    On Tue, Apr 11, 2017 at 3:33 PM, Norbert Illés
    <norbert.e.il...@ericsson.com <mailto:norbert.e.il...@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-requ...@lists.openstack.org?subject:unsubscribe
        <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>



    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:
    openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
    <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>




--
Best regards,
Peter Razumovsky


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to