On Wed, Aug 19, 2015 at 10:24 PM, Assaf Muller <amul...@redhat.com> wrote:
> > > On Wed, Aug 19, 2015 at 2:34 PM, Gal Sagie <gal.sa...@gmail.com> wrote: > >> Hello all, >> >> Recently i have came across two use cases that having "binding" >> information, or metadata >> for networks can be useful. (similar to the port binding profile for that >> matter) >> >> For example: >> >> 1) In project Kuryr we want to have a binding information which maps the >> Neutron network >> to docker network (And we might want to do it prior to the docker >> network being created, >> that is assign a network that is ready to be attached) so this field >> also needs to be editable >> (just like the port binding profile) >> >> 2) For multi site OpenStack (multi cloud) use cases we might want to >> share information which >> binds logically same network that is created at each OpenStack cloud >> site (and hence the ID's >> are different). >> (Something like this could be useful for project Tricircle for >> example) >> >> 3) Use cases for multi controllers environments? (each controller manage >> different networks?) >> >> I believe adding such optional field to the network API is really low >> risk due to its being optional >> and i believe other use cases can be found to leverage it. >> > > I wonder if we should just add a key/pair tuples "tags" or "metadata" > generic field instead. There's > been similar requests floating about that could also use a place to dump > their data in. > I think something similar was proposed as part of QoS but it was decided against. I personally think that having metadata for the entities (networks and ports) makes a lot of sense. > > >> >> Feel free to share ideas/comments. >> >> If there are no strong objections to it, i will add an RFE/Spec to add >> this ability. >> >> Thanks >> Gal. >> >> >> >> __________________________________________________________________________ >> 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 > >
__________________________________________________________________________ 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
