<div dir="ltr">I don't have cycles to support this development, but I do think that the function is worth while, wether you are using a 3rd party IPAM model or not, there are plenty of developers who expect a specific IP Address (even if it was randomly assigned via some other process, like booting without defining a fixed IP).  This is what drives many in the whole "I must have floating IPs, because I don't want to use DNS and expect to have _my own_ IP addresses to re-use" model for many users where that's not really the best usage model (and causes all kinds of fun from a performance perspective if you don't have hardware accelerated routing/NAT enabled).<div><br></div><div>I also agree that model #2 is the better idea, but model #1 would be very useful.</div><div><br></div><div>Robert</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 2:31 PM, Jonathan Proulx <span dir="ltr"><<a href="mailto:jon@csail.mit.edu" target="_blank">jon@csail.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
We carry one small local change in Horizon and I'm trying to determine<br>
if there's enough community interst in similar things that we should<br>
go through the process of upsreaming it.<br>
<br>
In order to provide access to our preexisting self-service IPAM and<br>
DNS registration services we allow and infact encourage our users to<br>
specify the 'fixed' addresses of instances they boot (obviously this<br>
also relies on some other implementation details).<br>
<br>
To facilitate this we carry a local Horizon override that stuffs an<br>
extra text field into the create instance workflow.  This breaks every<br>
cycle and with Mitaka basically none of our code is reusable.  The<br>
upside is I seem to have to actual developer time I can apply to<br>
fixing this.<br>
<br>
In my dreams this happens upstream rather than in an override as<br>
configurable option that defaults to don't show it, or maybe as a<br>
generalizable hook for adding options available in the API but not in<br>
the default workflow.<br>
<br>
Before I attempt to persue that dream I'm curious if anyone alse has a<br>
similar need becuase if I really am the only one doing this tehn<br>
there's no point trying to upsream it.<br>
<br>
So anyone interested in:<br>
<br>
1) being able to set fixed ip address on networks in the Horizon<br>
   create instance workflow.<br>
<br>
2) a generalized way to insert additional API options into Horizon<br>
   workflows.<br>
<br>
I like #2 but that may be a bigger effort than my team has cycles to<br>
do on our own (but if other like it and have resources ...)<br>
<br>
-Jon<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</font></span></blockquote></div><br></div>