[Rdo-list] Icehouse Neutron DB code bug still persists?

Thu Jul 17 13:02:15 UTC 2014

Documentation issue is now tracking at:

https://bugs.launchpad.net/openstack-manuals/+bug/1343277

On Thu, Jul 17, 2014 at 8:26 AM, Kodiak Firesmith <kfiresmith at gmail.com> wrote:
> Ihar,
> Apologies!  I looked at this with fresh eyes this morning and realized
> that while neutron-server was listening on 9696 I hadn't yet put a
> rule into our enterprise iptables management module in Puppet for
> neutron-server yet, thus Neutron stuff was timing out when a user
> attempts to log into Horizon.
>
> Everything works well now - I'll make sure to pay the help forward by
> filing an Openstack documentation bug request that distils the missing
> steps that the RDO team helped me get through yesterday.
>
> Thanks so much!
>  - Kodiak
>
>
> Date: Thu, 17 Jul 2014 10:55:08 +0200
> From: Ihar Hrachyshka <ihrachys at redhat.com>
> To: rdo-list at redhat.com
> Subject: Re: [Rdo-list] Icehouse Neutron DB code bug still persists?
> Message-ID: <53C78F6C.3070106 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 16/07/14 18:58, Kodiak Firesmith wrote:
>> Of course setting up Neutron has taken Horizon offline:
>>
>> http://paste.openstack.org/show/86778/
>>
>
> Any interesting log messages for neutron service? Do basic neutron
> requests like 'neutron net-list' work?
>
>>
>> - Kodiak
>>
>> On Wed, Jul 16, 2014 at 12:34 PM, Kodiak Firesmith
>> <kfiresmith at gmail.com> wrote:
>>> Further modifying /etc/neutron/neutron.conf as follows allowed
>>> the neutron-db-manage goodness to happen:
>>>
>>> -service_plugins = router +service_plugins =
>>> neutron.services.l3_router.l3_
> router_plugin.L3RouterPlugin
>>>
>>> # neutron-db-manage --config-file /etc/neutron/neutron.conf
>>> --config-file /etc/neutron/plugin.ini upgrade head No handlers
>>> could be found for logger "neutron.common.legacy" INFO
>>> [alembic.migration] Context impl MySQLImpl. INFO
>>> [alembic.migration] Will assume non-transactional DDL. INFO
>>> [alembic.migration] Running upgrade None -> folsom INFO
>>> [alembic.migration] Running upgrade folsom -> 2c4af419145b ...
>>> INFO  [alembic.migration] Running upgrade 1341ed32cc1e ->
>>> grizzly INFO  [alembic.migration] Running upgrade grizzly ->
>>> f489cf14a79c INFO  [alembic.migration] Running upgrade
>>> f489cf14a79c -> 176a85fc7d79 ... INFO  [alembic.migration]
>>> Running upgrade 49f5e553f61f -> 40b0aff0302e INFO
>>> [alembic.migration] Running upgrade 40b0aff0302e -> havana INFO
>>> [alembic.migration] Running upgrade havana -> e197124d4b9 ...
>>> INFO  [alembic.migration] Running upgrade 538732fa21e1 ->
>>> 5ac1c354a051 INFO  [alembic.migration] Running upgrade
>>> 5ac1c354a051 -> icehouse
>>>
>>> I am now cautiously optimistic that I'm back on track - will
>>> report back with success fail.  If success I'll submit a
>>> documentation bug to the docs.openstack people.
>>>
>>> Here's my tables now: http://paste.openstack.org/show/86776/
>>>
>>> Thanks a million!
>>>
>>> - Kodiak
>>>
>>> On Wed, Jul 16, 2014 at 11:15 AM, Kodiak Firesmith
>>> <kfiresmith at gmail.com> wrote:
>>>> Thanks again Kuba!
>>>>
>>>> So I think it's gotten farther.  I replaced the line on
>>>> /etc/neutron/neutron.conf:
>>>>
>>>> -core_plugin = ml2 +core_plugin = neutron.plugins.ml2.plugin.
>>>> Ml2Plugin
>>>>
>>>> Then I re-ran the neutron-db-manage as seen in the paste below.
>>>> It's gotten past ml2 and now is erroring out on 'router':
>>>>
>>>> http://paste.openstack.org/show/86759/
>>>>
>>>>
>>>> - Kodiak
>>>>
>>>> On Wed, Jul 16, 2014 at 11:01 AM, Jakub Libosvar
>>>> <libosvar at redhat.com> wrote:
>>>>> On 07/16/2014 04:57 PM, Kodiak Firesmith wrote:
>>>>>> Hello Kuba, Thanks for the reply.  I used the ml2 ini file
>>>>>> as my core plugin per the docs and did what you mentioned.
>>>>>> It resulted in a traceback unfortunately.
>>>>>>
>>>>>> Here is a specific accounting of what I did:
>>>>>> http://paste.openstack.org/show/86756/
>>>>>
>>>>> Ah, this is because we don't load full path from entry_points
>>>>> for plugins in neutron-db-manage (we didn't fix this because
>>>>> this dependency is going to be removed soon).
>>>>>
>>>>> Can you please try to change core_plugin in neutron.conf to
>>>>>
>>>>> core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin
>>>>>
>>>>> and re-run neutron-db-manage.
>>>>>
>>>>> Thanks, Kuba
>>>>>>
>>>>>> So it looks like maybe there is an issue with the ml2
>>>>>> plugin as the openstack docs cover it so far as how it
>>>>>> works with the RDO packages.
>>>>>>
>>>>>> Another admin reports that stuff "just works" in RDO
>>>>>> packstack - maybe there is some workaround in Packstack or
>>>>>> maybe it uses another driver and not ML2?
>>>>>>
>>>>>> Thanks again, - Kodiak
>>>>>>
>>>>>> On Wed, Jul 16, 2014 at 8:54 AM, Jakub Libosvar
>>>>>> <libosvar at redhat.com> wrote:
>>>>>>> On 07/16/2014 02:25 PM, Kodiak Firesmith wrote:
>>>>>>>> Hello, First go-round with Openstack and first post on
>>>>>>>> the list so bear with me...
>>>>>>>>
>>>>>>>> I've been working through the manual installation of
>>>>>>>> RDO using the docs.openstack installation guide.
>>>>>>>> Everything went smoothly for the most part until
>>>>>>>> Neutron.  It appears I've been hit by the same bug(?)
>>>>>>>> discussed here:
>>>>>>>> http://www.marshut.com/ithyup/net-create-issue.html#ithzts,
>>>>>>>> and here:
>>>>>>>> https://www.redhat.com/archives/rdo-list/2014-March/msg00005.html
>>>>>>>>
>>>>>>>>
> ...among other places.
>>>>>>>>
>>>>>>>> Upon first launch of the neutron-server daemon, this
>>>>>>>> appears in the neutron-server log file:
>>>>>>>> http://paste.openstack.org/show/86614/
>>>>>>>>
>>>>>>>> And once you go into the db you can see that a bunch of
>>>>>>>> tables are not created that should be.
>>>>>>>>
>>>>>>>> As the first link alludes to, it looks like a MyISAM /
>>>>>>>> InnoDB formatting mix-up but I'm no MySQL guy so I
>>>>>>>> can't prove that.
>>>>>>>>
>>>>>>>> I would really like if someone on the list who is a bit
>>>>>>>> more experienced with this stuff could please see if
>>>>>>>> the suspicions raised in the links above are correct,
>>>>>>>> and if so, could the RDO people please provide a
>>>>>>>> workaround to get me back up and running with our test
>>>>>>>> deployment?
>>>>>>>>
>>>>>>>> Thanks! - Kodiak
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Rdo-list mailing list Rdo-list at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/rdo-list
>>>>>>>>
>>>>>>> Hi Kodiak,
>>>>>>>
>>>>>>> I think there is a bug in documentation, I'm missing
>>>>>>> running neutron-db-manage command to create scheme for
>>>>>>> neutron. Can you please try to 1. stop neutron-server 2.
>>>>>>> create a new database 3. set connection string in
>>>>>>> neutron.conf 4. run neutron-db-manage --config-file
>>>>>>> /etc/neutron/neutron.conf --config-file
>>>>>>> <path_to_your_core_plugin_file.ini> upgrade head 5. start
>>>>>>> neutron-server
>>>>>>>
>>>>>>> Kuba
>>>>>
>>
>> _______________________________________________ Rdo-list mailing
>> list Rdo-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTx49sAAoJEC5aWaUY1u577IoH/A8xk9HwDgJYJ6M2T11D3Yt+
> VkRyZvR8drsVl2GaX51uQF4F9HWNgT6zhZqk4Y9n8MvTtG66XIUI7K0KW51uU05/
> Ki4NaD9RrkVMIvNGExCSOzcpuUaCYmTOjDVoHkKT+jp+vdRcjNrFZHtI7IE1qGpI
> BSbhNzV8htJJiFI40dsjJgZgutmqORvU79oFZDADcUMQnb/tIH9hw5xSAWe2+dzi
> IzUq88Brd90t8tteAAauNaHYcx4yG9dGZ7xaXi0FNqOhw/WzaVm8U/UkKmvEatoV
> NBlnbliuPBBtttGr/EtOtUcyo9eiNN1P+IvmoJgz8dSvbX95vAXZBGA+2Nq/ecQ=
> =dPVj
> -----END PGP SIGNATURE-----