<div dir="ltr"><div>Ideally I'd like the provider network to handle dhcp by itself without an additional network for the instance. I would have thought that enable_isolated_metadata=true would allow any instances provisioned on the provider network access to the dhcp server.  Is there an additional setting to allow a flat provider network to make use of the dhcp (dnsmasq) agents on the network nodes?</div><div><br></div><div>Thanks,</div><div>Matt</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 8:55 AM, Curtis <span dir="ltr"><<a href="mailto:serverascode@gmail.com" target="_blank">serverascode@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Oct 24, 2017 at 1:58 PM, Matthew Czajka <<a href="mailto:mattczajka@gmail.com">mattczajka@gmail.com</a>> wrote:<br>
> Oh hey there Curtis!<br>
><br>
>> Basically I expect there is no dhcp service. Double check the network has<br>
>> dhcp?<br>
><br>
> There's DHCP running on the net nodes, but the dhcp logs don't show any<br>
> errors or warnings<br>
<br>
</span>Sorry I missed this...<br>
<br>
But is the provider network setup to provide dhcp? If it's not<br>
supposed to, then what we will often do is give an instance two<br>
networks, one for "management" that can use the metadata system and<br>
one that is on the provider network which may not have dhcp support<br>
from openstack.<br>
<br>
<br>
Thanks,<br>
Curtis.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> In the DHCP logs, the only difference I can see is when booting from<br>
> provider it says its building the host file in /var/lib/neutron/dhcp/ while<br>
> booting from a self-service network, it says building in /var/lib/neutron/.<br>
><br>
> I have enable_isolated_metadata = True in the dhcp config.  But I noticed<br>
> that the dnsmasq logs dont show a DHCPDISCOVER or OFFER for the provider IP<br>
> I try to boot with. It shows for a self-service network.<br>
><br>
>> You could test with a config drive if you wanted to verify, or don't want<br>
>> dhcp service.<br>
><br>
> I don't want to use config drive since ceph is the backend, it might mess up<br>
> instance migrations I believe?<br>
><br>
> Thanks,<br>
> Matt<br>
><br>
><br>
> On Fri, Oct 20, 2017 at 2:09 PM, Curtis <<a href="mailto:serverascode@gmail.com">serverascode@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Oct 19, 2017 at 5:22 PM, Matthew Czajka <<a href="mailto:mattczajka@gmail.com">mattczajka@gmail.com</a>><br>
>> wrote:<br>
>> > Hi All,<br>
>> ><br>
>> ><br>
>> ><br>
>> > I’m running into an issue with a new Ocata deployment. I’m unable to<br>
>> > boot an<br>
>> > instance directly from the provider network. Instance logs show that it<br>
>> > keeps repeating “failed to raise interfaces” so it doesn’t get an IP<br>
>> > assigned, and then can’t reach the metatdata servers.<br>
>> ><br>
>> ><br>
>> ><br>
>> > Booting an instance from a self-service network works fine, can ping<br>
>> > other<br>
>> > internal IPs within the vlan, and can assign and use a floating IP.<br>
>> ><br>
>> ><br>
>> ><br>
>> > Deployment is running linux bridge, with a flat network for provider. 3<br>
>> > controllers, 3 network nodes, and 2 compute nodes. Using dhcpdump I can<br>
>> > see<br>
>> > DHCP requests being made, but no acknowledgement afterwards. If I<br>
>> > console<br>
>> > into the server and assign the public IP statically, that IP then works.<br>
>> > It’s only at boot (or reboot), that the instance can’t grab the IP.<br>
>> ><br>
>> ><br>
>> ><br>
>> > Any help would be appreciated, I’ve been banging my head over this for a<br>
>> > while.<br>
>><br>
>> Hey Matt :),<br>
>><br>
>> To get metadata there has to be a dhcp server or router configured, or<br>
>> use config drive. Presumably there is no dhcp service running via<br>
>> neutron in your situation, so it can't get an IP nor the metadata<br>
>> route injected. You could test with a config drive if you wanted to<br>
>> verify, or don't want dhcp service. Sometimes organizations refuse<br>
>> dhcp services on networks, but I'm guessing that is not the case in<br>
>> this situation.<br>
>><br>
>> Basically I expect there is no dhcp service. Double check the network has<br>
>> dhcp?<br>
>><br>
>> Thanks,<br>
>> Curtis.<br>
>><br>
>> ><br>
>> ><br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > Matt C<br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > OpenStack-operators mailing list<br>
>> > <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Blog: <a href="http://serverascode.com" rel="noreferrer" target="_blank">serverascode.com</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Blog: <a href="http://serverascode.com" rel="noreferrer" target="_blank">serverascode.com</a><br>
</font></span></blockquote></div><br></div>