Open Stack

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