Re: [openstack-dev] [TripleO][CI][QA][HA][Eris][LCOO] Validating HA on upstream

[Georg Kunz]

Hi Adam,

> Raoul Scarazzini  wrote:
> >On 06/03/2018 13:27, Adam Spiers wrote:
> >> Hi Raoul and all,
> >> Sorry for joining this discussion late!
> >[...]
> >> I do not work on TripleO, but I'm part of the wider OpenStack
> >> sub-communities which focus on HA[0] and more recently,
> >> self-healing[1].  With that hat on, I'd like to suggest that maybe
> >> it's possible to collaborate on this in a manner which is agnostic to
> >> the deployment mechanism.  There is an open spec on this>
> >> https://review.openstack.org/#/c/443504/
> >> which was mentioned in the Denver PTG session on destructive testing
> >> which you referenced[2].
> >[...]
> >>    https://www.opnfv.org/community/projects/yardstick
> >[...]
> >> Currently each sub-community and vendor seems to be reinventing HA
> >> testing by itself to some extent, which is easier to accomplish in
> >> the short-term, but obviously less efficient in the long-term.  It
> >> would be awesome if we could break these silos down and join efforts!
> >> :-)
> >
> >Hi Adam,
> >First of all thanks for your detailed answer. Then let me be honest
> >while saying that I didn't know yardstick.
> 
> Neither did I until Sydney, despite being involved with OpenStack HA for
> many years ;-)  I think this shows that either a) there is room for improved
> communication between the OpenStack and OPNFV communities, or b) I
> need to take my head out of the sand more often ;-)
> 
> >I need to start from scratch
> >here to understand what this project is. In any case, the exact meaning
> >of this thread is to involve people and have a more comprehensive look
> >at what's around.
> >The point here is that, as you can see from the tripleo-ha-utils spec
> >[1] I've created, the project is meant for TripleO specifically. On one
> >side this is a significant limitation, but on the other one, due to the
> >pluggable nature of the project, I think that integrations with other
> >software like you are proposing is not impossible.
> 
> Yep.  I totally sympathise with the tension between the need to get
> something working quickly, vs. the need to collaborate with the community
> in the most efficient way.
> 
> >Feel free to add your comments to the review.
> 
> The spec looks great to me; I don't really have anything to add, and I don't
> feel comfortable voting in a project which I know very little about.
> 
> >In the meantime, I'll check yardstick to see which kind of bridge we
> >can build to avoid reinventing the wheel.
> 
> Great, thanks!  I wish I could immediately help with this, but I haven't had 
> the
> chance to learn yardstick myself yet.  We should probably try to recruit
> someone from OPNFV to provide advice.  I've cc'd Georg who IIRC was the
> person who originally told me about yardstick :-)  He is an NFV expert and is
> also very interested in automated testing efforts:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2017-
> November/124942.html
> 
> so he may be able to help with this architectural challenge.

Thank you for bringing this up here. Better collaboration and sharing of 
knowledge, methodologies and tools across the communities is really what I'd 
like to see and facilitate. Hence, I am happy to help.

I have already started to advertise the newly proposed QA SIG in the OPNFV test 
WG and I'll happily do the same for the self-healing SIG and any HA testing 
efforts in general. There is certainly some overlapping interest in these 
testing aspects between the QA SIG and the self-healing SIG and hence 
collaboration between both SIGs is crucial.

One remark regarding tools and frameworks: I consider the true value of a SIG 
to be a place for talking about methodologies and best practices: What do we 
need to test? What are the challenges? How can we approach this across 
communities? The tools and frameworks are important and we should investigate 
which tools are available, how good they are, how much they fit a given 
purpose, but at the end of the day they are tools meant to enable well designed 
testing methodologies.

> Also you should be aware that work has already started on Eris, the extreme
> testing framework proposed in this user story:
> 
> http://specs.openstack.org/openstack/openstack-user-stories/user-
> stories/proposed/openstack_extreme_testing.html
> 
> and in the spec you already saw:
> 
> https://review.openstack.org/#/c/443504/
> 
> You can see ongoing work here:
> 
> https://github.com/LCOO/eris
> https://openstack-
> lcoo.atlassian.net/wiki/spaces/LCOO/pages/13393034/Eris+-
> +Extreme+Testing+Framework+for+OpenStack
> 
> It looks like there is a plan to propose a new SIG for this, although 
> personally I
> would be very happy to see it adopted by the self-healing SIG, since this
> framework is exactly what is needed for testing any self-healing mechanism.
> 
> I'm hoping that Sampath and/or Gautum will chip in here, since I think they're
> currently the main drivers for Eris.
> 
> 

Re: [openstack-dev] [qa] feedback on OPNFV test tools and extreme testing

[Georg Kunz]

Hi Gautam,

Thanks for the update. Just reach out to me if you need further infos, contact 
persons, support, etc.

Best regards
Georg

From: Gautam Divgi [mailto:gautamdi...@gmail.com]
Sent: Tuesday, November 28, 2017 4:59 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [qa] feedback on OPNFV test tools and extreme 
testing

Hi Georg,
I am working with Sampath on extreme testing. Have not had a chance to look at 
the tools past the cursory glance through the documents. It is however on my 
list to do a complete eval of them.
Thanks,
Gautam.

On Tue, Nov 28, 2017 at 2:49 AM, Georg Kunz 
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>> wrote:
Hi guys,

I wanted to come back to you regarding conversion we had in Sydney about the 
OPNFV tools. I am curious about your thoughts on tools such as Yardstick (and 
Functest) and in which way they meet or do not meet your requirements for 
extreme testing. In case you found the time to look at them - I know we are all 
busy - it would be great to learn your feedback. Next week is an OPNFV hackfest 
(the OPNFV equivalent to the PTG) and that's a good opportunity to discuss and 
incorporate new features and improvements. So, just let me know.

Best regards
Georg

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] feedback on OPNFV test tools and extreme testing

[Georg Kunz]

Hi guys,

I wanted to come back to you regarding conversion we had in Sydney about the 
OPNFV tools. I am curious about your thoughts on tools such as Yardstick (and 
Functest) and in which way they meet or do not meet your requirements for 
extreme testing. In case you found the time to look at them - I know we are all 
busy - it would be great to learn your feedback. Next week is an OPNFV hackfest 
(the OPNFV equivalent to the PTG) and that's a good opportunity to discuss and 
incorporate new features and improvements. So, just let me know.

Best regards
Georg

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Massively distributed] Optimizing the interaction of OpenStack components

[Georg Kunz]

Hi Ronan,

> First of all, sorry for the late response. I took a one-week vacation after 
> the
> Summit to visit the US.

No problem at all. I hope you had a great time.

> > Nevertheless, one concrete thing which came to my mind, is this
> > proposed improvement of the interaction between Nova and Neutron:
> > https://review.openstack.org/#/c/390513/
> >
> > In a nutshell, the idea is that Neutron adds more information to a
> > port object so that Nova does not need to make multiple calls to
> > Neutron to collect all required networking information. It seems to
> > have stalled for the time being, but bringing forward the edge
> > computing use case might increase the interest again.
> 
> Thanks for pointing such amelioration. This is a good use case to start with. 
> It
> should help to understand common patterns in the workflow that can be
> optimized. Let's see if we can implement an analysis with osp-utils that
> automatically highlight such pattern.

Thanks a lot for the links. I'll dig into the tools to get a better 
understanding and
make up my mind on how a potential analysis might look like.

I unfortunately missed to join yesterday's working group meeting. Just to 
confirm,
the IRC meetings are every two weeks on Wednesday at 15 UTC. Is that still 
correct?

Best regards
Georg

> Any comments/remarks on how we can do that is more than welcome.
> 
> Best regards,
> 
> [1] https://github.com/BeyondTheClouds/enos
> [2] https://www.youtube.com/watch?v=xwT08H02Nok
> [3] https://osprofiler.readthedocs.io/
> [4] https://github.com/BeyondTheClouds/osp-utils
> [5] http://enos.irisa.fr/html/seqdiag/v1/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Massively distributed] Optimizing the interaction of OpenStack components

[Georg Kunz]

Hi Ronan,
hi Adrien,

we talked yesterday in the edge/massively distributed working group meeting 
about optimizations of the control traffic between OpenStack components. 
Besides investigating different message busses, we agreed that it is also worth 
looking at how different OpenStack components interact. My understanding is 
that you have already developed tracing tools for this.

Nevertheless, one concrete thing which came to my mind, is this proposed 
improvement of the interaction between Nova and Neutron:
https://review.openstack.org/#/c/390513/

In a nutshell, the idea is that Neutron adds more information to a port object 
so that Nova does not need to make multiple calls to Neutron to collect all 
required networking information. It seems to have stalled for the time being, 
but bringing forward the edge computing use case might increase the interest 
again.

Best regards
Georg
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [gluon] Regarding multi-network and multi-tenant support

[Georg Kunz]

Hi Mohammad

> I have question regarding multi-networks and multi-tenants
> Currently Gluon supported only one network and subnet i.e GluonNetwork and 
> GluonSubnet respectively
> which i can see hard code values at path 
> https://github.com/openstack/gluon/blob/aa7edbf878c64829ef2e028c8cd0e5bb36ea1d51/gluon/plugin/core.py
>  #line number 164 and 174
> Please let know if you have plan to add mult-inetwork functionality ?

Thank you for checking out Gluon. The GluonNetwork and GluonSubnet you are 
referring to do not represent the (tenant) networks that Gluon can support. In 
fact, the actual (tenant) networks only exist in the respective networking 
backend (i.e. SDN controller) and are configured through the Proton APIs.

The GluonNetwork and GluonSubnet are currently used only as vehicles to expose 
the network ports which are configured via Gluon to Nova. Specifically, we 
collect all Gluon ports underneath the GluonNetworks and GluonSubnet because 
Neutron ports currently have to exist on a network and subnet according to the 
Neutron data model. In the networking backend, Gluon ports can belong to 
different (tenant) networks.

Best regards
Georg
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev