[openstack-dev] [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible architectures for image synchronisation

Csatari, Gergely (Nokia - HU/Budapest) gergely.csatari at nokia.com
Mon Jun 11 10:44:20 UTC 2018


Hi, 

Going inline. 

-----Original Message-----
From: Erno Kuvaja [mailto:ekuvaja at redhat.com] 
Sent: Friday, June 8, 2018 3:18 PM

Hi,

Answering inline.

Best,
Erno "jokke" Kuvaja

On Thu, Jun 7, 2018 at 11:49 AM, Csatari, Gergely (Nokia -
HU/Budapest) <gergely.csatari at nokia.com> wrote:
> 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?
glance_store library
> How is it possible to implement location aware synchronisation 
> (synchronise images only to those cloud instances where they are needed)?
This needs bit of hooking. We need to update the locations into Glance once the replication has happened.
[G0]: Okay, but how to avoid the replication to sites where the image is not needed?

> Is it possible to have different OpenStack versions in the different 
> cloud instances?
In my understanding it's not supported to mix versions within OpenStack cloud apart from during upgrade.
[G0]: Understood. This might be a problem ont he long run. With lots of edge cloud instance it can not be guaranteed, that all of them are upgraded in one go. 

> Can a cloud instance use the locally synchronised images in case of a 
> network connection break?
That depends a lot of the implementation. If there is local glance node with replicated db and store, yes.
[G0]: So we need a replicated Glance DB, a store and a backend in every edge cloud instance for this?
How the database would be syncronised in this case?

> Is it possible to implement this without storing database credentials 
> ont he edge cloud instances?
Again depending of the deployment. You definitely cannot have both, access during network outage and access without db credentials. if one needs to have local access of images without db credentials, there is always possibility for the local Ceph back-end with remote glance-api node. In this case Nova can talk directly to the local Ceph back-end and communicate with centralized glance-api that has the credentials to the db. The problem with loosing the network in this scenario is that Nova will have no idea if the user has rights to use the image or not and it will not know the path to that image's data.
[G0]: Okay

> Independent synchronisation service:
>
> If I understood [1] 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].
>
> [1]: https://mixmatch.readthedocs.io/en/latest/
>
> [2]: https://doodle.com/poll/bddg65vyh4qwxpk5
[G0]: Please add your availability here.

Thanks, 
Gerg0 

>
>
>
> 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>; 
> 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] 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
>
>
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>


More information about the OpenStack-dev mailing list