openstack team mailing list archive

[Balamurugan V G <balamuruganvg@xxxxxxxxx>]

Ok thanks, this helps a lot. But isnt this being done to avoid those
disruptions/issues with networking after a restart. Do you mean do
doing this will result in disruptions after a restart?

Regards,
Balu

On Wed, Apr 24, 2013 at 9:12 PM, Steve Heistand <steve.heistand@xxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The network node probably wont be running quantum server just one
> of the agents, so you put the command in one of those configs not
> quantum-server.
>
> That is what Im doing currently and it is working for me.
> at some point if you have running VMs with active network
> connections and need to restart quantum for some reason this
> 'may' interrupt their connections. something to keep in mind.
>
> steve
>
>
> On 04/24/2013 08:32 AM, Balamurugan V G wrote:
>> Right now, I have a single node setup on which I am qualifying my use cases but
>> eventually I will have a controller node, network node and several compute nodes. In
>> that case, do you mean it should something like this?
>>
>> Controller : post-start of quantum-server.cong Network :   post-start of
>> quantum-server.cong Compute:  pre-start of  quantum-plugin-openvswitch-agent.conf
>>
>> Thanks, Balu
>>
>> On Wed, Apr 24, 2013 at 8:52 PM, Steve Heistand <steve.heistand@xxxxxxxx> wrote: it
>> was mentioned to me (by Mr Mihaiescu) that this only works if controller and network
>> node are on the same machine. For the compute nodes I had forgotten its in a
>> different place. On them I am doing it in a pre-start script in
>> quantum-plugin-openvswitch-agent.conf. if the controller/network are on different
>> machines certainly in the quantum-server.conf work on which ever one of them is
>> actually using it, if it doesnt the command will have to be in a different startup
>> script.
>>
>> It was also mentioned that putting things in /etc/rc.local and then restarting all
>> the quantum related services might work too.
>>
>> steve
>>
>> On 04/24/2013 08:15 AM, Balamurugan V G wrote:
>>>>> Thanks Steve.
>>>>>
>>>>> I came across another way at
>>>>> https://bugs.launchpad.net/quantum/+bug/1084355/comments/15. It seems to work
>>>>> as well. But your solution is simpler :)
>>>>>
>>>>> Regards, Balu
>>>>>
>>>>>
>>>>> On Wed, Apr 24, 2013 at 7:41 PM, Steve Heistand <steve.heistand@xxxxxxxx>
>>>>> wrote: I put it in the file:/etc/init/quantum-server.conf
>>>>>
>>>>> post-start script /usr/bin/quantum-ovs-cleanup exit 1 end script
>>>>>
>>>>>
>>>>> On 04/24/2013 02:45 AM, Balamurugan V G wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It seems due to an OVS quantum bug, we need to run the utility
>>>>>>>> quantum-ovs-cleanup before any of the quantum services start, upon a
>>>>>>>> server reboot.
>>>>>>>>
>>>>>>>> Where is the best place to put this utility to run automatically when a
>>>>>>>> server reboots so that the OVS issue is automatically addressed? A script
>>>>>>>> in /etc/init.d or just plugging in a call for quantum-ovs-cleanup in an
>>>>>>>> existing script?
>>>>>>>>
>>>>>>>> Thanks, Balu
>>>>>>>>
>>>>>>>> _______________________________________________ Mailing list:
>>>>>>>> https://launchpad.net/~openstack Post to     :
>>>>>>>> openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>>>>>>>> https://launchpad.net/~openstack More help   :
>>>>>>>> https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>
>>
>
> - --
> ************************************************************************
>  Steve Heistand                          NASA Ames Research Center
>  email: steve.heistand@xxxxxxxx          Steve Heistand/Mail Stop 258-6
>  ph: (650) 604-4369                      Bldg. 258, Rm. 232-5
>  Scientific & HPC Application            P.O. Box 1
>  Development/Optimization                Moffett Field, CA 94035-0001
> ************************************************************************
>  "Any opinions expressed are those of our alien overlords, not my own."
>
> # For Remedy                        #
> #Action: Resolve                    #
> #Resolution: Resolved               #
> #Reason: No Further Action Required #
> #Tier1: User Code                   #
> #Tier2: Other                       #
> #Tier3: Assistance                  #
> #Notification: None                 #
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEARECAAYFAlF3/W0ACgkQoBCTJSAkVrHdnwCgrnCfjN1NKCml+jFPtHk0s4iA
> Nx0An3g6abwQons0jMXkJLu4oBhiZ4ot
> =zh9U
> -----END PGP SIGNATURE-----