Open Stack

Hi Bharath,

As further discussed in today's IRC meeting [1], the image creation
proposal you laid out seems a reasonable near term approach.

It also doesn't preclude future enhancements to do image-download during
VNFD on-boarding (image pre-positiong in a multi-site scenario). In that
case VNFD in the Catalog will already have references to glance image(s) in
the target VIM and the VNF creation can directly proceed to the
instantiation phase.

On the Flavor and Network creation I would strongly suggest to stick with
Heat resources and leverage TOSCA -> HOT conversion to achieve them and not
go directly to Nova and Neutron for this purpose.

thanks,
Sridhar

[1]
http://eavesdrop.openstack.org/meetings/tacker/2016/tacker.2016-01-26-17.00.log.html

On Tue, Jan 26, 2016 at 6:19 AM, bharath thiruveedula <
bharath_ves at hotmail.com> wrote:

> Hi Tackers,
>
> I have uploaded a new patchset for the automatic resource creation
> spec[1]. I haven't addressed some comments and as I am unable to attend to
> mitaka midcycle meetup, I am sharing below few thoughts on this spec.
>
> *Image Creation*:
>
> In the latest patchset, image creation at the time of onboarding, is the
> only reason for maintaining state for VNFD. As we discussed earlier, it may
> get difficult for the new users to understand "*state for templates?".* So
> it is better to  move image creation too on VNF creation. So if the
> template has uri, for the first VNF creation, we create the image and store
> image id for future VNF deployments. So using this option, we can provide
> parametrization of templates for images also and we can remove the
> statefulness for VNFD.
>
> *Flavor Creaton:*
>
> We can apply the same above rule in this case also. we store flavor IDs
> while deploying the first VNF and later reuse the same IDs.
>
> *Network Creation:*
>
> We can apply same rule here.
>
> Let me know your comments
>
> [1]https://review.openstack.org/#/c/250291/
>
> Regards
> Bharath T
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160126/fd7fde2e/attachment.html>