Re: [openstack-dev] [vitrage] Extending Topology

[Muhammad Usman]

Thanks Ifat,

For guiding me to how to start with contribution on implementation side.

Meanwhile, I am looking at blueprints and bugs before attending next
meeting.

-- 

*Regards*

*Muhammad Usman*
Application Engineer
LMK Resources (pvt) Limited
www.lmkr.com
+92 (323) 5599 068

On Fri, Sep 22, 2017 at 5:22 AM, Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi Usman,
>
>
>
> Great to hear back from you J
>
>
>
> You are more than welcome to join our efforts. You can look at the list of
> blueprints[1], suggest new ones, implement existing, or solve bugs[2].
> Whatever you chose, we will be happy to assist.
>
>
>
> The ways to contact Vitrage developers are here in the mailing list, or on
> #openstack-vitrage IRC channel. In addition, we meet every Wednesday at
> 8:00 UTC on #openstack-meeting-4, so you can join and discuss whatever
> topic you are interested in.
>
>
>
> [1] https://blueprints.launchpad.net/vitrage
>
> [2] https://bugs.launchpad.net/vitrage
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
> *From: *Muhammad Usman <usman...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Thursday, 21 September 2017 at 4:59
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [vitrage] Extending Topology
>
>
>
> Dear Ifat,
>
>
>
> Usman is here. Previously, I contacted you for contributing to OpenStack
> Vitrage project but could not  follow up with you for sometime due to
> various reasons.
>
>
>
> However, to get actively involved in OpenStack project, I have decided to
> join OpenStack Summit in Sydney.
>
>
>
> Also, based on my previous experience withe Vitrage project that is
> already in shape, so its not easy to propose new ideas.
>
>
>
> Therefore, a better way to start contributing to development side with
> already proposed and on-going development.
>
>
> --
>
>
> * Regards*
>
>
> *Muhammad Usman*
> Application Engineer
> LMK Resources (pvt) Limited
> www.lmkr.com
> +92 (323) 5599 068
>
>
>
>
>
> __
> 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 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] [vitrage] Extending Topology

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Usman,

Great to hear back from you ☺

You are more than welcome to join our efforts. You can look at the list of 
blueprints[1], suggest new ones, implement existing, or solve bugs[2]. Whatever 
you chose, we will be happy to assist.

The ways to contact Vitrage developers are here in the mailing list, or on 
#openstack-vitrage IRC channel. In addition, we meet every Wednesday at 8:00 
UTC on #openstack-meeting-4, so you can join and discuss whatever topic you are 
interested in.

[1] https://blueprints.launchpad.net/vitrage
[2] https://bugs.launchpad.net/vitrage

Best Regards,
Ifat.

From: Muhammad Usman <usman...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, 21 September 2017 at 4:59
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [vitrage] Extending Topology

Dear Ifat,

Usman is here. Previously, I contacted you for contributing to OpenStack 
Vitrage project but could not  follow up with you for sometime due to various 
reasons.

However, to get actively involved in OpenStack project, I have decided to join 
OpenStack Summit in Sydney.

Also, based on my previous experience withe Vitrage project that is already in 
shape, so its not easy to propose new ideas.

Therefore, a better way to start contributing to development side with already 
proposed and on-going development.

--

Regards

Muhammad Usman
Application Engineer
LMK Resources (pvt) Limited
www.lmkr.com<http://www.lmkr.com/>
+92 (323) 5599 068


__
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] [vitrage] Extending Topology

[Muhammad Usman]

Dear Ifat,

Usman is here. Previously, I contacted you for contributing to OpenStack
Vitrage project but could not  follow up with you for sometime due to
various reasons.

However, to get actively involved in OpenStack project, I have decided to
join OpenStack Summit in Sydney.

Also, based on my previous experience withe Vitrage project that is already
in shape, so its not easy to propose new ideas.

Therefore, a better way to start contributing to development side with
already proposed and on-going development.

-- 

*Regards*

*Muhammad Usman*
Application Engineer
LMK Resources (pvt) Limited
www.lmkr.com
+92 (323) 5599 068

On Mon, Mar 27, 2017 at 7:32 PM, Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi,
>
> Let me try and explain the more general use case.
>
> You can query OVS for the switches information, and understand how they
> are mapped to one another. This is not enough for knowing the exact route
> of the network traffic for a certain VM.
>
> A certain switch can be connected to more than one other switch. You can,
> as you said, query the network type (encapsulation) information from
> Neutron. But then you will need in addition to query the rules of the
> specific switch from OVS, in order to know which route to take for each
> encapsulation type.
>
> Another problematic use case is when the switches are not connected to
> each other. The traffic can be redirected by a network-stack software
> component, so you will have to query it in addition in order to tell the
> route.
>
> And on top of all this, we need to think how to best represent this
> information in Vitrage (i.e. how to draw the graph, which vertices to
> connect to one another, etc.).
>
> IMO, this is all feasible and will give a lot of value to Vitrage. Just
> not easy to implement.
>
> Best Regards,
> Ifat.
>
>
> On 22/03/2017, 08:50, "Muhammad Usman"  wrote:
>
> Hello Ifat,
>
> I tried to see more in depth about the issues you mentioned regarding
> the extension of vSwitches. Due to a lot of complexity involved in
> generating this topology and associated effects, I believe we need to
> setup some baseline (e.g. adding a configuration file for specifying
> bridges in existing deployment setup). Then using that baseline,
> topology can be constructed as well as type of network can be
> extracted from neutron and associated path followed (e.g. vlan or
> vxlan). However, more general case you mentioned, I cannot get it. Do
> you mean nova-network?
>
> Regarding the sunburst representation -  Yes I agree, if you want to
> keep compute hierarchy separate then addition of networking components
> is not a good idea.
>
> Also, suggestions from other vitrage members are welcomed.
>
>
> > On Thu, Mar 16, 2017 at 6:44 PM, Afek, Ifat (Nokia - IL) <
> > ifat.a...@nokia.com > wrote:
> >
> >> Hi,
> >>
> >>
> >>
> >> Adding switches to the Vitrage topology is generally a good idea,
> but the
> >> implementation might be very complex. Your diagram shows a simple
> use
> > case,
> >> where all switches are linked to one another and it is easy to
> determine
> >> the effect of a failure on the vms. However, in the more general
> case
> > there
> >> might be switches without a connecting port (e.g. they might be
> connected
> >> via the network stack). In such cases, it is not clear how to model
> the
> >> switches topology in Vitrage. Another case to consider is when the
> >> network
> >> type affects the packets path, like vlan vs. vxlan. If you have an
> idea
> >> of
> >> how to solve these issues, I will be happy to hear it.
> >>
> >>
> >>
> >> Regarding the sunburst representation – I’m not sure I understand
> your
> >> diagram. Currently the sunburst is meant to show (only) the compute
> >> hierarchy: zones, hosts and instances. It is arranged in a
> containment
> >> relationship, i.e. every instance on the outer ring appears next to
> its
> >> host in the inner ring. If you add the bridges in the middle, you
> lose
> > this
> >> containment relationship. Can you please explain to me the suggested
> >> diagram?
> >>
> >>
> >>
> >> BTW, you can send such questions to OpenStack mailing list (
> >> openstack-dev@lists.openstack.org ) with [vitrage]
> tag in
> > the title, and
> >> possibly get replies from other contributors as well.
> >>
> >>
> >>
> >> Best Regards,
> >>
> >> Ifat.
> >>
> >>
> >>
> >>
> >>
> >> *From: *Muhammad Usman >
> >> *Date: *Monday, 13 March 2017 at 09:16
> >>
> >> *To: *"Afek, Ifat (Nokia - IL)"  >
> >> *Cc: *JungSu Han >
> >> *Subject: *Re: OpenStack Vitrage
> >>
> >>
>  

Re: [openstack-dev] [vitrage] Extending Topology

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

Let me try and explain the more general use case.

You can query OVS for the switches information, and understand how they are 
mapped to one another. This is not enough for knowing the exact route of the 
network traffic for a certain VM.

A certain switch can be connected to more than one other switch. You can, as 
you said, query the network type (encapsulation) information from Neutron. But 
then you will need in addition to query the rules of the specific switch from 
OVS, in order to know which route to take for each encapsulation type.

Another problematic use case is when the switches are not connected to each 
other. The traffic can be redirected by a network-stack software component, so 
you will have to query it in addition in order to tell the route.

And on top of all this, we need to think how to best represent this information 
in Vitrage (i.e. how to draw the graph, which vertices to connect to one 
another, etc.).

IMO, this is all feasible and will give a lot of value to Vitrage. Just not 
easy to implement.

Best Regards,
Ifat.


On 22/03/2017, 08:50, "Muhammad Usman"  wrote:

Hello Ifat,

I tried to see more in depth about the issues you mentioned regarding
the extension of vSwitches. Due to a lot of complexity involved in
generating this topology and associated effects, I believe we need to
setup some baseline (e.g. adding a configuration file for specifying
bridges in existing deployment setup). Then using that baseline,
topology can be constructed as well as type of network can be
extracted from neutron and associated path followed (e.g. vlan or
vxlan). However, more general case you mentioned, I cannot get it. Do
you mean nova-network?

Regarding the sunburst representation -  Yes I agree, if you want to
keep compute hierarchy separate then addition of networking components
is not a good idea.

Also, suggestions from other vitrage members are welcomed.


> On Thu, Mar 16, 2017 at 6:44 PM, Afek, Ifat (Nokia - IL) <
> ifat.a...@nokia.com > wrote:
>
>> Hi,
>>
>>
>>
>> Adding switches to the Vitrage topology is generally a good idea, but the
>> implementation might be very complex. Your diagram shows a simple use
> case,
>> where all switches are linked to one another and it is easy to determine
>> the effect of a failure on the vms. However, in the more general case
> there
>> might be switches without a connecting port (e.g. they might be connected
>> via the network stack). In such cases, it is not clear how to model the
>> switches topology in Vitrage. Another case to consider is when the
>> network
>> type affects the packets path, like vlan vs. vxlan. If you have an idea
>> of
>> how to solve these issues, I will be happy to hear it.
>>
>>
>>
>> Regarding the sunburst representation – I’m not sure I understand your
>> diagram. Currently the sunburst is meant to show (only) the compute
>> hierarchy: zones, hosts and instances. It is arranged in a containment
>> relationship, i.e. every instance on the outer ring appears next to its
>> host in the inner ring. If you add the bridges in the middle, you lose
> this
>> containment relationship. Can you please explain to me the suggested
>> diagram?
>>
>>
>>
>> BTW, you can send such questions to OpenStack mailing list (
>> openstack-dev@lists.openstack.org ) with [vitrage] tag in
> the title, and
>> possibly get replies from other contributors as well.
>>
>>
>>
>> Best Regards,
>>
>> Ifat.
>>
>>
>>
>>
>>
>> *From: *Muhammad Usman >
>> *Date: *Monday, 13 March 2017 at 09:16
>>
>> *To: *"Afek, Ifat (Nokia - IL)" >
>> *Cc: *JungSu Han >
>> *Subject: *Re: OpenStack Vitrage
>>
>>
>>
>> Hi Ifat,
>>
>> I attached our idea of extending the Vitrage Topology to include Virtual
>> switches.
>>
>> The reason, I mentioned about adding switches part in Vitrage is because
>> we experienced looping issues that effect all infrastructure resources
>> (i.e. physical host as well as vm's) performance. Therefore, it's
> important
>> to monitor the virtual switches as well to assist overall monitoring/RCA
>> tasks.
>>
>> I think this idea will extend the Vitrage scope to touch some portion of
>> SDN (e.g. if we consider the SDN managed virtual switches) as well.
>>
>>
>>
>> On Thu, Mar 9, 2017 at 6:49 PM, Muhammad Usman  > wrote:
>>
>> Dear Ifat,
>>
>> Thanks for your guidance, I managed to install Vitrage properly using
>> Master branches for both OpenStack and Vitrage.
>>

[openstack-dev] [vitrage] Extending Topology

[Muhammad Usman]

Hello Ifat,

I tried to see more in depth about the issues you mentioned regarding
the extension of vSwitches. Due to a lot of complexity involved in
generating this topology and associated effects, I believe we need to
setup some baseline (e.g. adding a configuration file for specifying
bridges in existing deployment setup). Then using that baseline,
topology can be constructed as well as type of network can be
extracted from neutron and associated path followed (e.g. vlan or
vxlan). However, more general case you mentioned, I cannot get it. Do
you mean nova-network?

Regarding the sunburst representation -  Yes I agree, if you want to
keep compute hierarchy separate then addition of networking components
is not a good idea.

Also, suggestions from other vitrage members are welcomed.


> On Thu, Mar 16, 2017 at 6:44 PM, Afek, Ifat (Nokia - IL) <
> ifat.a...@nokia.com > wrote:
>
>> Hi,
>>
>>
>>
>> Adding switches to the Vitrage topology is generally a good idea, but the
>> implementation might be very complex. Your diagram shows a simple use
> case,
>> where all switches are linked to one another and it is easy to determine
>> the effect of a failure on the vms. However, in the more general case
> there
>> might be switches without a connecting port (e.g. they might be connected
>> via the network stack). In such cases, it is not clear how to model the
>> switches topology in Vitrage. Another case to consider is when the
>> network
>> type affects the packets path, like vlan vs. vxlan. If you have an idea
>> of
>> how to solve these issues, I will be happy to hear it.
>>
>>
>>
>> Regarding the sunburst representation – I’m not sure I understand your
>> diagram. Currently the sunburst is meant to show (only) the compute
>> hierarchy: zones, hosts and instances. It is arranged in a containment
>> relationship, i.e. every instance on the outer ring appears next to its
>> host in the inner ring. If you add the bridges in the middle, you lose
> this
>> containment relationship. Can you please explain to me the suggested
>> diagram?
>>
>>
>>
>> BTW, you can send such questions to OpenStack mailing list (
>> openstack-dev@lists.openstack.org ) with [vitrage] tag in
> the title, and
>> possibly get replies from other contributors as well.
>>
>>
>>
>> Best Regards,
>>
>> Ifat.
>>
>>
>>
>>
>>
>> *From: *Muhammad Usman >
>> *Date: *Monday, 13 March 2017 at 09:16
>>
>> *To: *"Afek, Ifat (Nokia - IL)" >
>> *Cc: *JungSu Han >
>> *Subject: *Re: OpenStack Vitrage
>>
>>
>>
>> Hi Ifat,
>>
>> I attached our idea of extending the Vitrage Topology to include Virtual
>> switches.
>>
>> The reason, I mentioned about adding switches part in Vitrage is because
>> we experienced looping issues that effect all infrastructure resources
>> (i.e. physical host as well as vm's) performance. Therefore, it's
> important
>> to monitor the virtual switches as well to assist overall monitoring/RCA
>> tasks.
>>
>> I think this idea will extend the Vitrage scope to touch some portion of
>> SDN (e.g. if we consider the SDN managed virtual switches) as well.
>>
>>
>>
>> On Thu, Mar 9, 2017 at 6:49 PM, Muhammad Usman  > wrote:
>>
>> Dear Ifat,
>>
>> Thanks for your guidance, I managed to install Vitrage properly using
>> Master branches for both OpenStack and Vitrage.
>>
>> Now, I will look into the visualization as well as other aspects.
>>
>>
>>
>>
>>
>> On Thu, Mar 9, 2017 at 2:43 PM, Afek, Ifat (Nokia - IL) <
>> ifat.a...@nokia.com > wrote:
>>
>> Hi,
>>
>>
>>
>> I have also noticed this problem, that Vitrage Ocata is not compatible
>> with Horizon Newton.
>>
>> If you just want an OpenStack working, you should use a stable version.
>> Stable/Ocata is the newest one (just released a few weeks ago). On the
>> other hand, if you want to contribute code, you better take the master
>> branch. Alternatively, you can take stable/ocata for all projects, and
>> the
>> master for Vitrage. This should work (for now, since Pike has just
> started).
>>
>>
>>
>> Best Regards,
>>
>> Ifat.
>>
>>
>>
>> *From: *Muhammad Usman >
>> *Date: *Wednesday, 8 March 2017 at 15:21
>>
>>
>> *To: *"Afek, Ifat (Nokia - IL)" >
>> *Cc: *JungSu Han >
>> *Subject: *Re: OpenStack Vitrage
>>
>>
>>
>> Ifat,
>>
>> after adding the mentioned line in /etc/heat/policy.json first error "You
>> are not authorized to use global_index" seems to be solved.
>>
>> However, in Horizon I still see same error (file is attached).
>>
>> So, After looking inside the code I found that I installed OpenStack
>> using
>> stable/newton branch but Vitrage is installed from Master branch. Since,
>> there are few changes in code (python-vitrageclient/
> vitrageclient/client.py)
>> that's why I think this error is occurring. Therefore, I