[openstack-dev] [Neutron] reservation of fixed ip
Sławek Kapłoński
slawek at kaplonski.pl
Thu May 22 18:00:31 UTC 2014
Hello,
Thanks for answears and info about this project - I will take a look on
that for sure :)
For me now reservation of fixed ips is enough and I don't know what
else can be reserved in neutron. Floating IP you can now assign to
tenant and this is some kind of reservation. Maybe someone else will
have other ideas about resources for reservation from neutron.
--
Pozdrawiam
Sławek Kapłoński
slawek at kaplonski.pl
Dnia Thu, 22 May 2014 10:15:11 -0700
Nikolay Starodubtsev <nstarodubtsev at mirantis.com> napisał:
> Hi,
> I'm agree with Pablo. We've looked at Neutron resource reservations
> some time ago.
> But we can't decide which resources should be reserved and this
> question has been delayed.
>
>
>
> Nikolay Starodubtsev
>
> Software Engineer
>
> Mirantis Inc.
>
>
> Skype: dark_harlequine1
>
>
> 2014-05-22 10:00 GMT-07:00 Fuente, Pablo A <pablo.a.fuente at intel.com>:
>
> > Hi,
> > I'm part of a project that aims to manage Reservations on
> > OpenStack.
> > Maybe this could be implemented on it. The name of the project is
> > Blazar (ex Climate). Currently we have two reservation plugins: one
> > for physical host reservations and other for virtual instances
> > reservation. We are planning to implement some new plugins: volume
> > reservation and neutron resource reservation. For the later we are
> > still analyzing which resources reserve, but from this email seems
> > that fixed IP should be one of them. Of course we already have
> > implemented all the things needed to handle reservations in our
> > core code: reservation life cycle, leases states (under review),
> > notifications (using oslo), pluging mechanism for new resource
> > reservations, DB schema with alembic migrations, REST API (with
> > Pecan), etc. And yes, should be easy to try Blazar using our
> > Devstack integration. If you need more information about the
> > project please visit our wiki
> > [1] or send me an email.
> >
> > Pablo.
> >
> > [1] https://wiki.openstack.org/wiki/Climate
> >
> > On Wed, 2014-05-21 at 23:51 +0100, Salvatore Orlando wrote:
> > > In principle there is nothing that should prevent us from
> > > implementing an IP reservation mechanism.
> > >
> > >
> > > As with anything, the first thing to check is literature or
> > > "related work"! If any other IaaS system is implementing such a
> > > mechanism, is it exposed through the API somehow?
> > > Also this feature is likely to be provided by IPAM systems. If
> > > yes, what constructs do they use?
> > > I do not have the answers to this questions, but I'll try to
> > > document myself; if you have them - please post them here.
> > >
> > >
> > > This new feature would probably be baked into neutron's IPAM
> > > logic. When allocating an IP, first check from within the IP
> > > reservation pool, and then if it's not found check from standard
> > > allocation pools (this has non negligible impact on availability
> > > ranges management, but these are implementation details).
> > > Aspects to consider, requirement-wise, are:
> > > 1) Should reservations also be classified by "qualification" of
> > > the port? For instance, is it important to specify that an IP
> > > should be used for the gateway port rather than for a floating IP
> > > port? 2) Are reservations something that an admin could specify
> > > on a tenant-basis (hence an admin API extension), or an implicit
> > > mechanism that can be tuned using configuration variables (for
> > > instance create an IP reservation a for gateway port for a given
> > > tenant when a router gateway is set).
> > >
> > >
> > > I apologise if these questions are dumb. I'm just trying to frame
> > > this discussion into something which could then possibly lead to
> > > submitting a specification.
> > >
> > >
> > > Salvatore
> > >
> > >
> > > On 21 May 2014 21:37, Collins, Sean
> > > <Sean_Collins2 at cable.comcast.com> wrote:
> > > (Edited the subject since a lot of people filter based on
> > > the subject
> > > line)
> > >
> > > I would also be interested in reserved IPs - since we do
> > > not deploy the
> > > layer 3 agent and use the provider networking extension
> > > and a hardware
> > > router.
> > >
> > > On Wed, May 21, 2014 at 03:46:53PM EDT, Sławek Kapłoński
> > > wrote:
> > > > Hello,
> > > >
> > > > Ok, I found that now there is probably no such feature
> > > > to
> > > reserve fixed
> > > > ip for tenant. So I was thinking about add such feature
> > > > to
> > > neutron. I
> > > > mean that it should have new table with reserved ips in
> > > neutron
> > > > database and neutron will check this table every time
> > > > when
> > > new port
> > > > will be created (or updated) and IP should be associated
> > > with this
> > > > port. If user has got reserved IP it should be then
> > > > used for
> > > new port,
> > > > if IP is reserver by other tenant - it shouldn't be
> > > > used. What You are thinking about such possibility? Is
> > > > it possible
> > > to add it
> > > > in some future release of neutron?
> > > >
> > > > --
> > > > Best regards
> > > > Sławek Kapłoński
> > > > slawek at kaplonski.pl
> > > >
> > > >
> > > > Dnia Mon, 19 May 2014 20:07:43 +0200
> > > > Sławek Kapłoński <slawek at kaplonski.pl> napisał:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'm using openstack with neutron and ML2 plugin. Is
> > > > > there
> > > any way to
> > > > > reserve fixed IP from shared external network for one
> > > tenant? I know
> > > > > that there is possibility to create port with IP and
> > > > > later
> > > connect VM
> > > > > to this port. This solution is almost ok for me but
> > > problem is when
> > > > > user delete this instance - then port is also deleted
> > > > > and
> > > it is not
> > > > > reserved still for the same user and tenant. So maybe
> > > there is any
> > > > > solution to reserve it "permanent"?
> > > > > I know also about floating IPs but I don't use L3
> > > > > agents
> > > so this is
> > > > > probably not for me :)
> > > > >
> > > >
> > > > _______________________________________________
> > > > OpenStack-dev mailing list
> > > > OpenStack-dev at lists.openstack.org
> > > >
> > >
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > > --
> > > Sean M. Collins
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > >
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
More information about the OpenStack-dev
mailing list