Open Stack

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?

Thanks,
Matt


On Fri, Oct 27, 2017 at 8:55 AM, Curtis <serverascode at gmail.com> wrote:

> On Tue, Oct 24, 2017 at 1:58 PM, Matthew Czajka <mattczajka at gmail.com>
> wrote:
> > Oh hey there Curtis!
> >
> >> Basically I expect there is no dhcp service. Double check the network
> has
> >> dhcp?
> >
> > There's DHCP running on the net nodes, but the dhcp logs don't show any
> > errors or warnings
>
> Sorry I missed this...
>
> But is the provider network setup to provide dhcp? If it's not
> supposed to, then what we will often do is give an instance two
> networks, one for "management" that can use the metadata system and
> one that is on the provider network which may not have dhcp support
> from openstack.
>
>
> Thanks,
> Curtis.
>
> >
> > In the DHCP logs, the only difference I can see is when booting from
> > provider it says its building the host file in /var/lib/neutron/dhcp/
> while
> > booting from a self-service network, it says building in
> /var/lib/neutron/.
> >
> > I have enable_isolated_metadata = True in the dhcp config.  But I noticed
> > that the dnsmasq logs dont show a DHCPDISCOVER or OFFER for the provider
> IP
> > I try to boot with. It shows for a self-service network.
> >
> >> You could test with a config drive if you wanted to verify, or don't
> want
> >> dhcp service.
> >
> > I don't want to use config drive since ceph is the backend, it might
> mess up
> > instance migrations I believe?
> >
> > Thanks,
> > Matt
> >
> >
> > On Fri, Oct 20, 2017 at 2:09 PM, Curtis <serverascode at gmail.com> wrote:
> >>
> >> On Thu, Oct 19, 2017 at 5:22 PM, Matthew Czajka <mattczajka at gmail.com>
> >> wrote:
> >> > Hi All,
> >> >
> >> >
> >> >
> >> > I’m running into an issue with a new Ocata deployment. I’m unable to
> >> > boot an
> >> > instance directly from the provider network. Instance logs show that
> it
> >> > keeps repeating “failed to raise interfaces” so it doesn’t get an IP
> >> > assigned, and then can’t reach the metatdata servers.
> >> >
> >> >
> >> >
> >> > Booting an instance from a self-service network works fine, can ping
> >> > other
> >> > internal IPs within the vlan, and can assign and use a floating IP.
> >> >
> >> >
> >> >
> >> > Deployment is running linux bridge, with a flat network for provider.
> 3
> >> > controllers, 3 network nodes, and 2 compute nodes. Using dhcpdump I
> can
> >> > see
> >> > DHCP requests being made, but no acknowledgement afterwards. If I
> >> > console
> >> > into the server and assign the public IP statically, that IP then
> works.
> >> > It’s only at boot (or reboot), that the instance can’t grab the IP.
> >> >
> >> >
> >> >
> >> > Any help would be appreciated, I’ve been banging my head over this
> for a
> >> > while.
> >>
> >> Hey Matt :),
> >>
> >> To get metadata there has to be a dhcp server or router configured, or
> >> use config drive. Presumably there is no dhcp service running via
> >> neutron in your situation, so it can't get an IP nor the metadata
> >> route injected. You could test with a config drive if you wanted to
> >> verify, or don't want dhcp service. Sometimes organizations refuse
> >> dhcp services on networks, but I'm guessing that is not the case in
> >> this situation.
> >>
> >> Basically I expect there is no dhcp service. Double check the network
> has
> >> dhcp?
> >>
> >> Thanks,
> >> Curtis.
> >>
> >> >
> >> >
> >> >
> >> > Thanks,
> >> >
> >> > Matt C
> >> >
> >> >
> >> > _______________________________________________
> >> > OpenStack-operators mailing list
> >> > OpenStack-operators at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-operators
> >> >
> >>
> >>
> >>
> >> --
> >> Blog: serverascode.com
> >
> >
>
>
>
> --
> Blog: serverascode.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20171031/842c81b3/attachment.html>