Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support

2014-11-21 Thread Andrew Woodward 
Samuel,

As Vladimir noted, moving the br-mgmt assignment will be covered by
https://blueprints.launchpad.net/fuel/+spec/advanced-networking


On Fri, Nov 21, 2014 at 6:22 AM,   wrote:
> Mike,
>
>
>
> It sounds to be a good idea in order to indentify issues with blueprint and
> real uses cases.
>
> A doc can be a good media to share on this subject.
>
> Were you talking of this one  User stories:
> https://docs.google.com/a/mirantis.com/document/d/1iWeuXzV4-muLK3Nfx2IH8WI6yrawOXM5ZBqMCE5ZLzc/edit?
>
>
>
> Or should we create a new one?
>
>
>
>
>
> From: Mike Scherbakov [mailto:mscherba...@mirantis.com]
> Sent: vendredi 21 novembre 2014 12:52
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support
>
>
>
> Samuel, Vladimir,
>
> I see a little issue with blueprint and real use cases.
>
>
>
> Currently we do not collect use cases. Can we start doing this in some
> section of whether design doc, or in blueprint itself? We've got linux
> bonds, vxlan, multiple ranges for mgmt network, etc.
>
>
>
> On Fri, Nov 21, 2014 at 2:26 PM, Vladimir Kuklin 
> wrote:
>
> Hi, Samuel
>
>
>
> I think the case that you are talking about is an ability to use arbitrary
> interfaces for different purposes. AFAIK, this use case is covered by
> https://blueprints.launchpad.net/fuel/+spec/advanced-networking blueprint.
>
>
>
> On Fri, Nov 21, 2014 at 12:04 PM,  wrote:
>
> Hello,
>
>
>
> I have a question regarding  futur vxlan support implementation in fuel and
> the corresponding blueprint.
>
> Actually in the blueprint description there is nothing specify about the
> bridge used for vxlan traffic. In the previous implementation abandoned on
> gerrit the br-mgmt was assigned for the mesh role similary to what is done
> for gre segmentation.
>
> Can we consider to add a dedicated bridge for vxlan in order to have the
> capacity to not mix admin and vxlan (and optionnaly monitoring with zabbix)
> traffics on the same physical interface
>
>
>
> Regards
>
>
>
> Samuel Bartel
>
> IRC  #samuelbartel
>
>
>
> _
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
>
> Thank you.
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuk...@mirantis.com
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> Mike Scherbakov
> #mihgen
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confide

Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support

2014-11-21 Thread samuel.bartel 
Mike,

It sounds to be a good idea in order to indentify issues with blueprint and 
real uses cases.
A doc can be a good media to share on this subject.
Were you talking of this one  User stories: 
https://docs.google.com/a/mirantis.com/document/d/1iWeuXzV4-muLK3Nfx2IH8WI6yrawOXM5ZBqMCE5ZLzc/edit?

Or should we create a new one?


From: Mike Scherbakov [mailto:mscherba...@mirantis.com]
Sent: vendredi 21 novembre 2014 12:52
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support

Samuel, Vladimir,
I see a little issue with blueprint and real use cases.

Currently we do not collect use cases. Can we start doing this in some section 
of whether design doc, or in blueprint itself? We've got linux bonds, vxlan, 
multiple ranges for mgmt network, etc.

On Fri, Nov 21, 2014 at 2:26 PM, Vladimir Kuklin 
mailto:vkuk...@mirantis.com>> wrote:
Hi, Samuel

I think the case that you are talking about is an ability to use arbitrary 
interfaces for different purposes. AFAIK, this use case is covered by 
https://blueprints.launchpad.net/fuel/+spec/advanced-networking blueprint.

On Fri, Nov 21, 2014 at 12:04 PM, 
mailto:samuel.bar...@orange.com>> wrote:
Hello,

I have a question regarding  futur vxlan support implementation in fuel and the 
corresponding blueprint.
Actually in the blueprint description there is nothing specify about the bridge 
used for vxlan traffic. In the previous implementation abandoned on gerrit the 
br-mgmt was assigned for the mesh role similary to what is done for gre 
segmentation.
Can we consider to add a dedicated bridge for vxlan in order to have the 
capacity to not mix admin and vxlan (and optionnaly monitoring with zabbix) 
traffics on the same physical interface

Regards

Samuel Bartel
IRC  #samuelbartel


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com<http://www.mirantis.ru/>
www.mirantis.ru<http://www.mirantis.ru/>
vkuk...@mirantis.com<mailto:vkuk...@mirantis.com>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Mike Scherbakov
#mihgen

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support

2014-11-21 Thread Mike Scherbakov 
Samuel, Vladimir,
I see a little issue with blueprint and real use cases.

Currently we do not collect use cases. Can we start doing this in some
section of whether design doc, or in blueprint itself? We've got linux
bonds, vxlan, multiple ranges for mgmt network, etc.

On Fri, Nov 21, 2014 at 2:26 PM, Vladimir Kuklin 
wrote:

> Hi, Samuel
>
> I think the case that you are talking about is an ability to use arbitrary
> interfaces for different purposes. AFAIK, this use case is covered by
> https://blueprints.launchpad.net/fuel/+spec/advanced-networking blueprint.
>
> On Fri, Nov 21, 2014 at 12:04 PM,  wrote:
>
>>  Hello,
>>
>>
>>
>> I have a question regarding  futur vxlan support implementation in fuel
>> and the corresponding blueprint.
>>
>> Actually in the blueprint description there is nothing specify about the
>> bridge used for vxlan traffic. In the previous implementation abandoned on
>> gerrit the br-mgmt was assigned for the mesh role similary to what is done
>> for gre segmentation.
>>
>> Can we consider to add a dedicated bridge for vxlan in order to have the
>> capacity to not mix admin and vxlan (and optionnaly monitoring with zabbix)
>> traffics on the same physical interface
>>
>>
>>
>> Regards
>>
>>
>>
>> Samuel Bartel
>>
>> IRC  #samuelbartel
>>
>>
>>
>> _
>>
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
>> falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged 
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been 
>> modified, changed or falsified.
>> Thank you.
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support

2014-11-21 Thread Vladimir Kuklin 
Hi, Samuel

I think the case that you are talking about is an ability to use arbitrary
interfaces for different purposes. AFAIK, this use case is covered by
https://blueprints.launchpad.net/fuel/+spec/advanced-networking blueprint.

On Fri, Nov 21, 2014 at 12:04 PM,  wrote:

>  Hello,
>
>
>
> I have a question regarding  futur vxlan support implementation in fuel
> and the corresponding blueprint.
>
> Actually in the blueprint description there is nothing specify about the
> bridge used for vxlan traffic. In the previous implementation abandoned on
> gerrit the br-mgmt was assigned for the mesh role similary to what is done
> for gre segmentation.
>
> Can we consider to add a dedicated bridge for vxlan in order to have the
> capacity to not mix admin and vxlan (and optionnaly monitoring with zabbix)
> traffics on the same physical interface
>
>
>
> Regards
>
>
>
> Samuel Bartel
>
> IRC  #samuelbartel
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev