Open Stack

Hi,

I’ve added the following pros and cons to the different options:

  *   One Glance with multiple backends [1<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_with_multiple_backends>]
     *   Pros:
        *   Relatively easy to implement based on the current Glance architecture
     *   Cons:
        *   Requires the same Glance backend in every edge cloud instance
        *   Requires the same OpenStack version in every edge cloud instance (apart from during upgrade)
        *   Sensitivity for network connection loss is not clear
  *   Several Glances with an independent syncronisation service, sych via Glance API [2<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_sych_via_Glance_API>]
     *   Pros:
        *   Every edge cloud instance can have a different Glance backend
        *   Can support multiple OpenStack versions in the different edge cloud instances
        *   Can be extended to support multiple VIM types
     *   Cons:
        *   Needs a new synchronisation service
  *   Several Glances with an independent syncronisation service, synch using the backend [3<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend>]
     *   Pros:
        *   I could not find any
     *   Cons:
        *   Needs a new synchronisation service
  *   One Glance and multiple Glance API servers [4<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_and_multiple_Glance_API_servers>]
     *   Pros:
        *   Implicitly location aware
     *   Cons:
        *   First usage of an image always takes a long time
        *   In case of network connection error to the central Galnce Nova will have access to the images, but will not be able to figure out if the user have rights to use the image and will not have path to the images data
Are these correct? Do I miss anything?

Thanks,
Gerg0

[1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_with_multiple_backends
[2]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_sych_via_Glance_API
[3]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend
[4]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#One_Glance_and_multiple_Glance_API_servers






From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Monday, June 11, 2018 4:29 PM
To: Waines, Greg <Greg.Waines at windriver.com>; OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>; edge-computing at lists.openstack.org
Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

Hi,

Thanks for the comments.
I’ve updated the wiki: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment#Several_Glances_with_an_independent_syncronisation_service.2C_synch_using_the_backend

Br,
Gerg0

From: Waines, Greg [mailto:Greg.Waines at windriver.com]
Sent: Friday, June 8, 2018 1:46 PM
To: Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari at nokia.com<mailto:gergely.csatari at nokia.com>>; OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>; edge-computing at lists.openstack.org<mailto:edge-computing at lists.openstack.org>
Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

Responses in-lined below,
Greg.

From: "Csatari, Gergely (Nokia - HU/Budapest)" <gergely.csatari at nokia.com<mailto:gergely.csatari at nokia.com>>
Date: Friday, June 8, 2018 at 3:39 AM
To: Greg Waines <Greg.Waines at windriver.com<mailto:Greg.Waines at windriver.com>>, "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, "edge-computing at lists.openstack.org<mailto:edge-computing at lists.openstack.org>" <edge-computing at lists.openstack.org<mailto:edge-computing at lists.openstack.org>>
Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

Hi,

Going inline.

From: Waines, Greg [mailto:Greg.Waines at windriver.com]
Sent: Thursday, June 7, 2018 2:24 PM
I had some additional questions/comments on the Image Synchronization Options ( https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ):


One Glance with multiple backends

  *   In this scenario, are all Edge Clouds simply configured with the one central glance for its GLANCE ENDPOINT ?
     *   i.e. GLANCE is a typical shared service in a multi-region environment ?

[G0]: In my understanding yes.


  *   If so,
how does this OPTION support the requirement for Edge Cloud Operation when disconnected from Central Location ?

[G0]: This is an open question for me also.


Several Glances with an independent synchronization service    (PUSH)

  *   I refer to this as the PUSH model
  *   I don’t believe you have to ( or necessarily should) rely on the backend to do the synchronization of the images
     *   i.e. the ‘Synch Service’ could do this strictly through Glance REST APIs
(making it independent of the particular Glance backend ... and allowing the Glance Backends at Central and Edge sites to actually be different)
[G0]: Okay, I can update the wiki to reflect this. Should we keep the “synchronization by the backend” option as an other alternative?
[Greg] Yeah we should keep it as an alternative.

  *   I think the ‘Synch Service’ MUST be able to support ‘selective/multicast’ distribution of Images from Central to Edge for Image Synchronization
     *   i.e. you don’t want Central Site pushing ALL images to ALL Edge Sites ... especially for the small Edge Sites
[G0]: Yes, the question is how to define these synchronization policies.
[Greg] Agreed ... we’ve had some very high-level discussions with end users, but haven’t put together a proposal yet.

  *   Not sure ... but I didn’t think this was the model being used in mixmatch ... thought mixmatch was more the PULL model (below)

[G0]: Yes, this is more or less my understanding. I remove the mixmatch reference from this chapter.

One Glance and multiple Glance API Servers   (PULL)

  *   I refer to this as the PULL model
  *   This is the current model supported in StarlingX’s Distributed Cloud sub-project
     *   We run glance-api on all Edge Clouds ... that talk to glance-registry on the Central Cloud, and
     *   We have glance-api setup for caching such that only the first access to an particular image incurs the latency of the image transfer from Central to Edge
[G0]: Do you do image caching in Glance API or do you rely in the image cache in Nova? In the Forum session there were some discussions about this and I think the conclusion was that using the image cache of Nova is enough.
[Greg] We enabled image caching in the Glance API.
             I believe that Nova Image Caching caches at the compute node ... this would work ok for all-in-one edge clouds or small edge clouds.
             But glance-api caching caches at the edge cloud level, so works better for large edge clouds with lots of compute nodes.

  *
  *   this PULL model affectively implements the location aware synchronization you talk about below,  (i.e. synchronise images only to those cloud instances where they are needed)?


In StarlingX Distributed Cloud,
We plan on supporting both the PUSH and PULL model ... suspect there are use cases for both.

[G0]: This means that you need an architecture supporting both.
Just for my curiosity what is the use case for the pull model once you have the push model in place?
[Greg] The PULL model certainly results in the most efficient distribution of images ... basically images are distributed ONLY to edge clouds that explicitly use the image.
Also if the use case is NOT concerned about incurring the latency of the image transfer from Central to Edge on the FIRST use of image then the PULL model could be preferred ... TBD.

Here is the updated wiki: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[Greg] Looks good.

Greg.


Thanks,
Gerg0




From: "Csatari, Gergely (Nokia - HU/Budapest)" <gergely.csatari at nokia.com<mailto:gergely.csatari at nokia.com>>
Date: Thursday, June 7, 2018 at 6:49 AM
To: "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, "edge-computing at lists.openstack.org<mailto:edge-computing at lists.openstack.org>" <edge-computing at lists.openstack.org<mailto:edge-computing at lists.openstack.org>>
Subject: Re: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

Hi,

I did some work ont he figures and realised, that I have some questions related to the alternative options:

Multiple backends option:

  *   What is the API between Glance and the Glance backends?
  *   How is it possible to implement location aware synchronisation (synchronise images only to those cloud instances where they are needed)?
  *   Is it possible to have different OpenStack versions in the different cloud instances?
  *   Can a cloud instance use the locally synchronised images in case of a network connection break?
  *   Is it possible to implement this without storing database credentials ont he edge cloud instances?

Independent synchronisation service:

  *   If I understood [1<https://mixmatch.readthedocs.io/en/latest/>] correctly mixmatch can help Nova to attach a remote volume, but it will not help in synchronizing the images. is this true?


As I promised in the Edge Compute Group call I plan to organize an IRC review meeting to check the wiki. Please indicate your availability in [2<https://doodle.com/poll/bddg65vyh4qwxpk5>].

[1]: https://mixmatch.readthedocs.io/en/latest/
[2]: https://doodle.com/poll/bddg65vyh4qwxpk5

Br,
Gerg0

From: Csatari, Gergely (Nokia - HU/Budapest)
Sent: Wednesday, May 23, 2018 8:59 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>; edge-computing at lists.openstack.org<mailto:edge-computing at lists.openstack.org>
Subject: [edge][glance]: Wiki of the possible architectures for image synchronisation

Hi,

Here I send the wiki page [1<https://wiki.openstack.org/wiki/Image_handling_in_edge_environment>] where I summarize what I understood from the Forum session about image synchronisation in edge environment [2], [3].

Please check and correct/comment.

Thanks,
Gerg0


[1]: https://wiki.openstack.org/wiki/Image_handling_in_edge_environment
[2]: https://etherpad.openstack.org/p/yvr-edge-cloud-images
[3]: https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21768/image-handling-in-an-edge-cloud-infrastructure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180628/4b29c6e6/attachment.html>