Open Stack

On Fri, 2019-01-25 at 12:26 -0500, Jay Pipes wrote:
> On 01/25/2019 12:04 PM, Terry Wilson wrote:
> > On Thu, Jan 24, 2019 at 7:34 PM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
> > 
> > > As Sean also pointed that in patch that we should go for the approach of
> > > "making sure all attached interface to server is active, server is sshable
> > >   bthe efore server can be used in test" [1]. This is something we agreed
> > >   in Denver PTG for afazekas proposal[2].
> > > 
> > > If we see the  from user perspective , user can have an Active VM with
> > > active port which can flip to down in between of that port usage. This seems bug to me.
> > 
> > To me, this ignores real-world situations where a port status *can*
> > change w/o user interaction.
> 
> How is this ignoring that scenario?
the only case i know of for definity would be if the admin state is down
which should not prevent the vm from booting but neutron shoudl not allow network
connecitigy in this case.

> 
> > It seems weird to ignore a status change
> > if it is detected. In the case that we hit, it was a change to os-vif
> > where it was recreating a port.
> 
> Which was a bug, right?
yes kind of.
we could have fixed it by merging the nova change i had or 
reverting the os-vif change.
i revert the os-vif change as the nova change was hitting a different bug
in neutron. but only one entity. os-vif or the hyperviror should have been creating
the port on ovs. so it was a bug when both were.
> 
> > But it could just as easily be some vendor-specific "that port just
> > died" kind of thing.
> 
> In which case, the test waiting for SSH to be available would timeout 
> because connectivity would be broken anyway, no?
if it did not recover yes it would.
> 
>  >
> Why not update the status of the port if you
> > know it has changed? 
> 
> Sorry, I don't see where anyone is suggesting not changing the status of 
> the port if some non-bug real scenario changes the status of the port?
> 
> > Also, the patch itself (outside the ironic case) just adds a window
> > for the status to bounce.
> 
> Unless I'm mistaken, the patch is simply changing the condition that the 
> tempest test uses to identify broken VM connectivity. It will use the 
> SSH connectivity test instead of looking at the port status test.
> 
> The SSH test was determined to be a more stable test of VM network 
> connectivity than relying on the Neutron port status indicator which can 
> be a little flaky.
ssh is more reliable for hotpug as we needed to wait for the guest os to 
process the hotplug event. waithing for the vm to be pingable or sshable
is more reliable in that specific case. the port status being active simply
means that the port is curently configured by neutron. that gives you no knolage
of if the gust has processed the hotplug event.

in general im not sure if ssh connectivity would be more reliabel but if that
is what the test requires to work its better to expeclitly validate it then use
the port status as a proxy.
> 
> Or am I missing something?
its a valid question i think port status and vm connectity are two different things.

if you are writing an api test then port status hsould be suffient.
if you need to connect to the vm in any way it becomes a senario test
in which case wait for sshable or pingable might be more suitable.

not sure if i answer your question however.
> 
> -jay
> 
>