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).
I also agree that model #2 is the better idea, but model #1 would be very useful. Robert On Wed, May 25, 2016 at 2:31 PM, Jonathan Proulx <j...@csail.mit.edu> wrote: > Hi All, > > We carry one small local change in Horizon and I'm trying to determine > if there's enough community interst in similar things that we should > go through the process of upsreaming it. > > In order to provide access to our preexisting self-service IPAM and > DNS registration services we allow and infact encourage our users to > specify the 'fixed' addresses of instances they boot (obviously this > also relies on some other implementation details). > > To facilitate this we carry a local Horizon override that stuffs an > extra text field into the create instance workflow. This breaks every > cycle and with Mitaka basically none of our code is reusable. The > upside is I seem to have to actual developer time I can apply to > fixing this. > > In my dreams this happens upstream rather than in an override as > configurable option that defaults to don't show it, or maybe as a > generalizable hook for adding options available in the API but not in > the default workflow. > > Before I attempt to persue that dream I'm curious if anyone alse has a > similar need becuase if I really am the only one doing this tehn > there's no point trying to upsream it. > > So anyone interested in: > > 1) being able to set fixed ip address on networks in the Horizon > create instance workflow. > > 2) a generalized way to insert additional API options into Horizon > workflows. > > I like #2 but that may be a bigger effort than my team has cycles to > do on our own (but if other like it and have resources ...) > > -Jon > > -- > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators