On Wed, Jun 08, 2016 at 10:39:20AM +0000, Sam Betts (sambetts) wrote: > > > On 07/06/2016 23:59, "Kris G. Lindgren" > <klindg...@godaddy.com<mailto:klindg...@godaddy.com>> wrote: > > Replying to a digest so sorry for the copy and pastes.... > > > >> There's also been discussion of ways we could do ad-hoc changes in RAID > >> level, > >> based on flavor metadata, during the provisioning process (rather than > >> ahead of > >> time) but no code has been done for this yet, AFAIK. > > > > I'm still pretty interested in it, because I agree with anything said > > above about building RAID ahead-of-time not being convenient. I don't > > quite understand how such a feature would look like, we might add it as > > a topic for midcycle. > > This sounds like an interesting/acceptable way to handle this problem to me. > Update the node to set the desired raid state from the flavor. > > >> - Inspection is geared towards using a different network and dnsmasq > > >> infrastructure than what is in use for ironic/neutron. Which also means > >> that in > >> order to not conflict with dhcp requests for servers in ironic I need to > >> use > >> different networks. Which also means I now need to handle swinging server > >> ports > >> between different networks. > >> Inspector is designed to respond only to requests for nodes in the > >> inspection > > phase, so that it *doesn't* conflict with provisioning of nodes by Ironic. > > I've > > been using the same network for inspection and provisioning without issue > > -- so > > I'm not sure what problem you're encountering here. > > So I was mainly thinking about the use case of using inspector to onboard > unknown hosts into ironic (though I see didn't mention that). So in a > datacenter we are always on boarding servers. Right now we boot a linux > agent that "inventories" the box and adds it to our management system as a > node to be able to be consumed by a build request. My understanding is that > inspector supports this as of Mitaka. However, the install guide for > inspection states that you need to install its own dnsmasq instance for > inspection. To me this implies that this is suppose to be a separate > network. As if I have 2 dhcp servers running on the same L2 network I am > going to get races between the 2 dhcp servers for normal provisioning > activities. Especially if one dhcp server is configured to respond to > everything (so that it can onboard unknown hardware) and the other only to > specific hosts(ironic/neutron). The only way that wouldn't be an issue is if > both inspector and ironic/neutron are using th e same dhcp servers. Or am I missing something? > > Ironic inspector handles this by managing Iptables as a firewall service to > white/black list nodes, only allowing nodes that should be talking to the > Inspector's dnsmasq instance to be served by it. This avoids any DHCP races > between Ironic and Inspector.
To add to this, the primary reason this is done is because Neutron doesn't allow wildcard DHCP (there's a spec up for this, but it isn't moving quickly). // jim > > > ___________________________________________________________________ > Kris Lindgren > Senior Linux Systems Engineer > GoDaddy > __________________________________________________________________________ > 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
