Adding [api] topic.
On 01/08/2015 07:47 PM, Kevin Benton wrote:
Is there another openstack service that allows this so we can make the
API consistent between the two when this change is made?
Kevin, thank you VERY much for asking the above question and caring
about consistency in the APIs!
There was a discussion on the ML about this very area of the APIs, and
how there is current inconsistency to resolve:
http://openstack-dev.openstack.narkive.com/UbM1J7dH/horizon-all-status-vs-state
You were involved in that thread, so I know you're very familiar with
the problem domain :)
In the above thread, I mentioned that this really was something that the
API WG should tackle, and this here ML thread should be a catalyst for
getting that done.
What we need is a patch proposed to the openstack/api-wg that proposes
some guidelines around the REST API structure for "disabling some
resource for administrative purposes", with some content that discusses
the semantic differences between "state" and "status", and makes
recommendations on the naming of resource attributes that indicate an
admnistrative state.
Of course, this doesn't really address Jack M's question about whether
there should be a separate "mode" (in Jack's terms) to indicate that
some resource can be only manually assigned and not automatically
assigned. Personally, I don't feel there is a need for another mode. I
think if something has been administratively disabled, that an
administrator should still be able to manually alter that thing.
All the best,
-jay
On Thu, Jan 8, 2015 at 3:09 PM, Carl Baldwin <c...@ecbaldwin.net
<mailto:c...@ecbaldwin.net>> wrote:
I added a link to @Jack's post to the ML to the bug report [1]. I am
willing to support @Itsuro with reviews of the implementation and am
willing to consult if you need and would like to ping me.
Carl
[1] https://bugs.launchpad.net/neutron/+bug/1408488
On Thu, Jan 8, 2015 at 7:49 AM, McCann, Jack <jack.mcc...@hp.com
<mailto:jack.mcc...@hp.com>> wrote:
> +1 on need for this feature
>
> The way I've thought about this is we need a mode that stops the
*automatic*
> scheduling of routers/dhcp-servers to specific hosts/agents,
while allowing
> manual assignment of routers/dhcp-servers to those hosts/agents,
and where
> any existing routers/dhcp-servers on those hosts continue to
operate as normal.
>
> The maintenance use case was mentioned: I want to evacuate
routers/dhcp-servers
> from a host before taking it down, and having the scheduler add
new routers/dhcp
> while I'm evacuating the node is a) an annoyance, and b) causes a
service blip
> when I have to right away move that new router/dhcp to another host.
>
> The other use case is adding a new host/agent into an existing
environment.
> I want to be able to bring the new host/agent up and into the
neutron config, but
> I don't want any of my customers' routers/dhcp-servers scheduled
there until I've
> had a chance to assign some test routers/dhcp-servers and make
sure the new server
> is properly configured and fully operational.
>
> - Jack
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
