Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-20 Thread Aleksandr Didenko
Hi folks,

it turned out that one change has to be made in your plugins though. If
you're reusing 'netconfig' task for your custom roles, you need to remove
'configure_default_route' task from your roles (if you have it) and add
'hiera_default_route'. This is needed for proper default gateway
configuration for cases when public network is assigned on controllers
only. Here's an example of patch for plugin [0] and bug about it [1]

Regards,
Alex

[0] https://review.openstack.org/#/c/328225/2/deployment_tasks.yaml
[1] https://bugs.launchpad.net/fuel-plugins/+bug/1591117

On Tue, Jun 7, 2016 at 11:46 AM, Aleksandr Didenko 
wrote:

> Hi,
>
> you don't need to change anything in your plugin, we still have the same
> netconfig.pp task on all nodes even after bugfix.
>
> Regards,
> Alex
>
> On Tue, Jun 7, 2016 at 8:21 AM, Igor Zinovik 
> wrote:
>
>>   Hello,
>>
>> Aleksandr, one simple question: do I as a plugin developer for upcoming
>> Fuel 9.0 have
>> to worry about these network-related changes or not? HCF is approaching,
>> but patch
>> that you mentioned (342307 )
>> is still not merged. Do I need to spend time on understanding
>> it and change plugins deployment tasks
>> 
>> according to the netconfig.pp refactoring?
>>
>>
>> On 6 June 2016 at 11:12, Aleksandr Didenko  wrote:
>>
>>> Hi,
>>>
>>> a bit different patch is on review now [0]. Instead of silently
>>> replacing default gateway on the fly in netconfig.pp task it's putting new
>>> default gateway into Hiera. Thus we'll have idempotency for subsequent
>>> netconfig.pp runs even on Mongo roles. Also we'll have consistent network
>>> configuration data in Hiera which any plugin can rely on.
>>>
>>> I've built a custom ISO with this patch and run a set of custom tests on
>>> it to cover multi-role and multi-rack cases [1] plus BVT - everything
>>> worked fine.
>>>
>>> Please feel free to review and comment the patch [0].
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://review.openstack.org/324307
>>> [1] http://paste.openstack.org/show/508319/
>>>
>>> On Wed, Jun 1, 2016 at 4:47 PM, Aleksandr Didenko >> > wrote:
>>>
 Hi,

 YAQL expressions support for task dependencies has been added to
 Nailgun [0]. So now it's possible to fix network configuration idempotency
 issue without introducing new 'netconfig' task [1]. There will be no
 problems with loops in task graph in such case (tested on multiroles,
 worked fine). When we deprecate role-based deployment (even emulated), then
 we'll be able to remove all those additional conditions from manifests and
 remove 'configure_default_route' task completely. Please feel free to
 review and comment the patch [1].

 Regards,
 Alex

 [0] https://review.openstack.org/#/c/320861/
 [1] https://review.openstack.org/#/c/322872/

 On Wed, May 25, 2016 at 10:39 AM, Simon Pasquier <
 spasqu...@mirantis.com> wrote:

> Hi Adam,
> Maybe you want to look into network templates [1]? Although the
> documentation is a bit sparse, it allows you to define flexible network
> mappings.
> BR,
> Simon
> [1]
> https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates
>
> On Wed, May 25, 2016 at 10:26 AM, Adam Heczko 
> wrote:
>
>> Thanks Alex, will experiment with it once again although AFAIR it
>> doesn't solve thing I'd like to do.
>> I'll come later to you in case of any questions.
>>
>>
>> On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko <
>> adide...@mirantis.com> wrote:
>>
>>> Hey Adam,
>>>
>>> in Fuel we have the following option (checkbox) on Network Setting
>>> tab:
>>>
>>> Assign public network to all nodes
>>> When disabled, public network will be assigned to controllers only
>>>
>>> So if you uncheck it (by default it's unchecked) then public network
>>> and 'br-ex' will exist on controllers only. Other nodes won't even have
>>> "Public" network on node interface configuration UI.
>>>
>>> Regards,
>>> Alex
>>>
>>> On Wed, May 25, 2016 at 9:43 AM, Adam Heczko 
>>> wrote:
>>>
 Hello Alex,
 I have a question about the proposed changes.
 Is it possible to introduce new vlan and associated bridge only for
 controllers?
 I think about DMZ use case and possibility to expose public IPs/VIP
 and API endpoints on controllers on a completely separate L2 network
 (segment vlan/bridge) not present on any other nodes than controllers.
 Thanks.

 On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-07 Thread Aleksandr Didenko
Hi,

you don't need to change anything in your plugin, we still have the same
netconfig.pp task on all nodes even after bugfix.

Regards,
Alex

On Tue, Jun 7, 2016 at 8:21 AM, Igor Zinovik  wrote:

>   Hello,
>
> Aleksandr, one simple question: do I as a plugin developer for upcoming
> Fuel 9.0 have
> to worry about these network-related changes or not? HCF is approaching,
> but patch
> that you mentioned (342307 ) is
> still not merged. Do I need to spend time on understanding
> it and change plugins deployment tasks
> 
> according to the netconfig.pp refactoring?
>
>
> On 6 June 2016 at 11:12, Aleksandr Didenko  wrote:
>
>> Hi,
>>
>> a bit different patch is on review now [0]. Instead of silently replacing
>> default gateway on the fly in netconfig.pp task it's putting new default
>> gateway into Hiera. Thus we'll have idempotency for subsequent netconfig.pp
>> runs even on Mongo roles. Also we'll have consistent network configuration
>> data in Hiera which any plugin can rely on.
>>
>> I've built a custom ISO with this patch and run a set of custom tests on
>> it to cover multi-role and multi-rack cases [1] plus BVT - everything
>> worked fine.
>>
>> Please feel free to review and comment the patch [0].
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/324307
>> [1] http://paste.openstack.org/show/508319/
>>
>> On Wed, Jun 1, 2016 at 4:47 PM, Aleksandr Didenko 
>> wrote:
>>
>>> Hi,
>>>
>>> YAQL expressions support for task dependencies has been added to Nailgun
>>> [0]. So now it's possible to fix network configuration idempotency issue
>>> without introducing new 'netconfig' task [1]. There will be no problems
>>> with loops in task graph in such case (tested on multiroles, worked fine).
>>> When we deprecate role-based deployment (even emulated), then we'll be able
>>> to remove all those additional conditions from manifests and remove
>>> 'configure_default_route' task completely. Please feel free to review and
>>> comment the patch [1].
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://review.openstack.org/#/c/320861/
>>> [1] https://review.openstack.org/#/c/322872/
>>>
>>> On Wed, May 25, 2016 at 10:39 AM, Simon Pasquier >> > wrote:
>>>
 Hi Adam,
 Maybe you want to look into network templates [1]? Although the
 documentation is a bit sparse, it allows you to define flexible network
 mappings.
 BR,
 Simon
 [1]
 https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates

 On Wed, May 25, 2016 at 10:26 AM, Adam Heczko 
 wrote:

> Thanks Alex, will experiment with it once again although AFAIR it
> doesn't solve thing I'd like to do.
> I'll come later to you in case of any questions.
>
>
> On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko <
> adide...@mirantis.com> wrote:
>
>> Hey Adam,
>>
>> in Fuel we have the following option (checkbox) on Network Setting
>> tab:
>>
>> Assign public network to all nodes
>> When disabled, public network will be assigned to controllers only
>>
>> So if you uncheck it (by default it's unchecked) then public network
>> and 'br-ex' will exist on controllers only. Other nodes won't even have
>> "Public" network on node interface configuration UI.
>>
>> Regards,
>> Alex
>>
>> On Wed, May 25, 2016 at 9:43 AM, Adam Heczko 
>> wrote:
>>
>>> Hello Alex,
>>> I have a question about the proposed changes.
>>> Is it possible to introduce new vlan and associated bridge only for
>>> controllers?
>>> I think about DMZ use case and possibility to expose public IPs/VIP
>>> and API endpoints on controllers on a completely separate L2 network
>>> (segment vlan/bridge) not present on any other nodes than controllers.
>>> Thanks.
>>>
>>> On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <
>>> adide...@mirantis.com> wrote:
>>>
 Hi folks,

 we had to revert those changes [0] since it's impossible to propery
 handle two different netconfig tasks for multi-role nodes. So 
 everything
 stays as it was before - we have single task 'netconfig' to configure
 network for all roles and you don't need to change anything in your
 plugins. Sorry for inconvenience.

 Our current plan for fixing network idempotency is to keep one task
 but change 'cross-depends' parameter to yaql_exp. This will allow us 
 to use
 single 'netconfig' task for all roles but at the same time we'll be 
 able to
 properly order it: netconfig on non-controllers will be 

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-07 Thread Igor Zinovik
  Hello,

Aleksandr, one simple question: do I as a plugin developer for upcoming
Fuel 9.0 have
to worry about these network-related changes or not? HCF is approaching,
but patch
that you mentioned (342307 ) is
still not merged. Do I need to spend time on understanding
it and change plugins deployment tasks

according to the netconfig.pp refactoring?

On 6 June 2016 at 11:12, Aleksandr Didenko  wrote:

> Hi,
>
> a bit different patch is on review now [0]. Instead of silently replacing
> default gateway on the fly in netconfig.pp task it's putting new default
> gateway into Hiera. Thus we'll have idempotency for subsequent netconfig.pp
> runs even on Mongo roles. Also we'll have consistent network configuration
> data in Hiera which any plugin can rely on.
>
> I've built a custom ISO with this patch and run a set of custom tests on
> it to cover multi-role and multi-rack cases [1] plus BVT - everything
> worked fine.
>
> Please feel free to review and comment the patch [0].
>
> Regards,
> Alex
>
> [0] https://review.openstack.org/324307
> [1] http://paste.openstack.org/show/508319/
>
> On Wed, Jun 1, 2016 at 4:47 PM, Aleksandr Didenko 
> wrote:
>
>> Hi,
>>
>> YAQL expressions support for task dependencies has been added to Nailgun
>> [0]. So now it's possible to fix network configuration idempotency issue
>> without introducing new 'netconfig' task [1]. There will be no problems
>> with loops in task graph in such case (tested on multiroles, worked fine).
>> When we deprecate role-based deployment (even emulated), then we'll be able
>> to remove all those additional conditions from manifests and remove
>> 'configure_default_route' task completely. Please feel free to review and
>> comment the patch [1].
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/#/c/320861/
>> [1] https://review.openstack.org/#/c/322872/
>>
>> On Wed, May 25, 2016 at 10:39 AM, Simon Pasquier 
>> wrote:
>>
>>> Hi Adam,
>>> Maybe you want to look into network templates [1]? Although the
>>> documentation is a bit sparse, it allows you to define flexible network
>>> mappings.
>>> BR,
>>> Simon
>>> [1]
>>> https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates
>>>
>>> On Wed, May 25, 2016 at 10:26 AM, Adam Heczko 
>>> wrote:
>>>
 Thanks Alex, will experiment with it once again although AFAIR it
 doesn't solve thing I'd like to do.
 I'll come later to you in case of any questions.


 On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko <
 adide...@mirantis.com> wrote:

> Hey Adam,
>
> in Fuel we have the following option (checkbox) on Network Setting tab:
>
> Assign public network to all nodes
> When disabled, public network will be assigned to controllers only
>
> So if you uncheck it (by default it's unchecked) then public network
> and 'br-ex' will exist on controllers only. Other nodes won't even have
> "Public" network on node interface configuration UI.
>
> Regards,
> Alex
>
> On Wed, May 25, 2016 at 9:43 AM, Adam Heczko 
> wrote:
>
>> Hello Alex,
>> I have a question about the proposed changes.
>> Is it possible to introduce new vlan and associated bridge only for
>> controllers?
>> I think about DMZ use case and possibility to expose public IPs/VIP
>> and API endpoints on controllers on a completely separate L2 network
>> (segment vlan/bridge) not present on any other nodes than controllers.
>> Thanks.
>>
>> On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <
>> adide...@mirantis.com> wrote:
>>
>>> Hi folks,
>>>
>>> we had to revert those changes [0] since it's impossible to propery
>>> handle two different netconfig tasks for multi-role nodes. So everything
>>> stays as it was before - we have single task 'netconfig' to configure
>>> network for all roles and you don't need to change anything in your
>>> plugins. Sorry for inconvenience.
>>>
>>> Our current plan for fixing network idempotency is to keep one task
>>> but change 'cross-depends' parameter to yaql_exp. This will allow us to 
>>> use
>>> single 'netconfig' task for all roles but at the same time we'll be 
>>> able to
>>> properly order it: netconfig on non-controllers will be executed only
>>> aftetr 'virtual_ips' task.
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://review.openstack.org/#/c/320530/
>>>
>>>
>>> On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <
>>> adide...@mirantis.com> wrote:
>>>
 Hi all,

 please be aware that now we have two netconfig tasks (in Fuel 9.0+):

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-06 Thread Aleksandr Didenko
Hi,

a bit different patch is on review now [0]. Instead of silently replacing
default gateway on the fly in netconfig.pp task it's putting new default
gateway into Hiera. Thus we'll have idempotency for subsequent netconfig.pp
runs even on Mongo roles. Also we'll have consistent network configuration
data in Hiera which any plugin can rely on.

I've built a custom ISO with this patch and run a set of custom tests on it
to cover multi-role and multi-rack cases [1] plus BVT - everything worked
fine.

Please feel free to review and comment the patch [0].

Regards,
Alex

[0] https://review.openstack.org/324307
[1] http://paste.openstack.org/show/508319/

On Wed, Jun 1, 2016 at 4:47 PM, Aleksandr Didenko 
wrote:

> Hi,
>
> YAQL expressions support for task dependencies has been added to Nailgun
> [0]. So now it's possible to fix network configuration idempotency issue
> without introducing new 'netconfig' task [1]. There will be no problems
> with loops in task graph in such case (tested on multiroles, worked fine).
> When we deprecate role-based deployment (even emulated), then we'll be able
> to remove all those additional conditions from manifests and remove
> 'configure_default_route' task completely. Please feel free to review and
> comment the patch [1].
>
> Regards,
> Alex
>
> [0] https://review.openstack.org/#/c/320861/
> [1] https://review.openstack.org/#/c/322872/
>
> On Wed, May 25, 2016 at 10:39 AM, Simon Pasquier 
> wrote:
>
>> Hi Adam,
>> Maybe you want to look into network templates [1]? Although the
>> documentation is a bit sparse, it allows you to define flexible network
>> mappings.
>> BR,
>> Simon
>> [1]
>> https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates
>>
>> On Wed, May 25, 2016 at 10:26 AM, Adam Heczko 
>> wrote:
>>
>>> Thanks Alex, will experiment with it once again although AFAIR it
>>> doesn't solve thing I'd like to do.
>>> I'll come later to you in case of any questions.
>>>
>>>
>>> On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko <
>>> adide...@mirantis.com> wrote:
>>>
 Hey Adam,

 in Fuel we have the following option (checkbox) on Network Setting tab:

 Assign public network to all nodes
 When disabled, public network will be assigned to controllers only

 So if you uncheck it (by default it's unchecked) then public network
 and 'br-ex' will exist on controllers only. Other nodes won't even have
 "Public" network on node interface configuration UI.

 Regards,
 Alex

 On Wed, May 25, 2016 at 9:43 AM, Adam Heczko 
 wrote:

> Hello Alex,
> I have a question about the proposed changes.
> Is it possible to introduce new vlan and associated bridge only for
> controllers?
> I think about DMZ use case and possibility to expose public IPs/VIP
> and API endpoints on controllers on a completely separate L2 network
> (segment vlan/bridge) not present on any other nodes than controllers.
> Thanks.
>
> On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <
> adide...@mirantis.com> wrote:
>
>> Hi folks,
>>
>> we had to revert those changes [0] since it's impossible to propery
>> handle two different netconfig tasks for multi-role nodes. So everything
>> stays as it was before - we have single task 'netconfig' to configure
>> network for all roles and you don't need to change anything in your
>> plugins. Sorry for inconvenience.
>>
>> Our current plan for fixing network idempotency is to keep one task
>> but change 'cross-depends' parameter to yaql_exp. This will allow us to 
>> use
>> single 'netconfig' task for all roles but at the same time we'll be able 
>> to
>> properly order it: netconfig on non-controllers will be executed only
>> aftetr 'virtual_ips' task.
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/#/c/320530/
>>
>>
>> On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <
>> adide...@mirantis.com> wrote:
>>
>>> Hi all,
>>>
>>> please be aware that now we have two netconfig tasks (in Fuel 9.0+):
>>>
>>> - netconfig-controller - executed on controllers only
>>> - netconfig - executed on all other nodes
>>>
>>> puppet manifest is the same, but tasks are different. We had to do
>>> this [0] in order to fix network idempotency issues [1].
>>>
>>> So if you have 'netconfig' requirements in your plugin's tasks,
>>> please make sure to add 'netconfig-controller' as well, to work 
>>> properly on
>>> controllers.
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://bugs.launchpad.net/fuel/+bug/1541309
>>> [1]
>>> https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z
>>>
>>
>>
>>
>> 

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-06-01 Thread Aleksandr Didenko
Hi,

YAQL expressions support for task dependencies has been added to Nailgun
[0]. So now it's possible to fix network configuration idempotency issue
without introducing new 'netconfig' task [1]. There will be no problems
with loops in task graph in such case (tested on multiroles, worked fine).
When we deprecate role-based deployment (even emulated), then we'll be able
to remove all those additional conditions from manifests and remove
'configure_default_route' task completely. Please feel free to review and
comment the patch [1].

Regards,
Alex

[0] https://review.openstack.org/#/c/320861/
[1] https://review.openstack.org/#/c/322872/

On Wed, May 25, 2016 at 10:39 AM, Simon Pasquier 
wrote:

> Hi Adam,
> Maybe you want to look into network templates [1]? Although the
> documentation is a bit sparse, it allows you to define flexible network
> mappings.
> BR,
> Simon
> [1]
> https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates
>
> On Wed, May 25, 2016 at 10:26 AM, Adam Heczko 
> wrote:
>
>> Thanks Alex, will experiment with it once again although AFAIR it doesn't
>> solve thing I'd like to do.
>> I'll come later to you in case of any questions.
>>
>>
>> On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko <
>> adide...@mirantis.com> wrote:
>>
>>> Hey Adam,
>>>
>>> in Fuel we have the following option (checkbox) on Network Setting tab:
>>>
>>> Assign public network to all nodes
>>> When disabled, public network will be assigned to controllers only
>>>
>>> So if you uncheck it (by default it's unchecked) then public network and
>>> 'br-ex' will exist on controllers only. Other nodes won't even have
>>> "Public" network on node interface configuration UI.
>>>
>>> Regards,
>>> Alex
>>>
>>> On Wed, May 25, 2016 at 9:43 AM, Adam Heczko 
>>> wrote:
>>>
 Hello Alex,
 I have a question about the proposed changes.
 Is it possible to introduce new vlan and associated bridge only for
 controllers?
 I think about DMZ use case and possibility to expose public IPs/VIP and
 API endpoints on controllers on a completely separate L2 network (segment
 vlan/bridge) not present on any other nodes than controllers.
 Thanks.

 On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <
 adide...@mirantis.com> wrote:

> Hi folks,
>
> we had to revert those changes [0] since it's impossible to propery
> handle two different netconfig tasks for multi-role nodes. So everything
> stays as it was before - we have single task 'netconfig' to configure
> network for all roles and you don't need to change anything in your
> plugins. Sorry for inconvenience.
>
> Our current plan for fixing network idempotency is to keep one task
> but change 'cross-depends' parameter to yaql_exp. This will allow us to 
> use
> single 'netconfig' task for all roles but at the same time we'll be able 
> to
> properly order it: netconfig on non-controllers will be executed only
> aftetr 'virtual_ips' task.
>
> Regards,
> Alex
>
> [0] https://review.openstack.org/#/c/320530/
>
>
> On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <
> adide...@mirantis.com> wrote:
>
>> Hi all,
>>
>> please be aware that now we have two netconfig tasks (in Fuel 9.0+):
>>
>> - netconfig-controller - executed on controllers only
>> - netconfig - executed on all other nodes
>>
>> puppet manifest is the same, but tasks are different. We had to do
>> this [0] in order to fix network idempotency issues [1].
>>
>> So if you have 'netconfig' requirements in your plugin's tasks,
>> please make sure to add 'netconfig-controller' as well, to work properly 
>> on
>> controllers.
>>
>> Regards,
>> Alex
>>
>> [0] https://bugs.launchpad.net/fuel/+bug/1541309
>> [1]
>> https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z
>>
>
>
>
> __
> 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
>
>


 --
 Adam Heczko
 Security Engineer @ Mirantis Inc.


 __
 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:
>>> 

Re: [openstack-dev] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Simon Pasquier
Hi Adam,
Maybe you want to look into network templates [1]? Although the
documentation is a bit sparse, it allows you to define flexible network
mappings.
BR,
Simon
[1]
https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates

On Wed, May 25, 2016 at 10:26 AM, Adam Heczko  wrote:

> Thanks Alex, will experiment with it once again although AFAIR it doesn't
> solve thing I'd like to do.
> I'll come later to you in case of any questions.
>
>
> On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko  > wrote:
>
>> Hey Adam,
>>
>> in Fuel we have the following option (checkbox) on Network Setting tab:
>>
>> Assign public network to all nodes
>> When disabled, public network will be assigned to controllers only
>>
>> So if you uncheck it (by default it's unchecked) then public network and
>> 'br-ex' will exist on controllers only. Other nodes won't even have
>> "Public" network on node interface configuration UI.
>>
>> Regards,
>> Alex
>>
>> On Wed, May 25, 2016 at 9:43 AM, Adam Heczko 
>> wrote:
>>
>>> Hello Alex,
>>> I have a question about the proposed changes.
>>> Is it possible to introduce new vlan and associated bridge only for
>>> controllers?
>>> I think about DMZ use case and possibility to expose public IPs/VIP and
>>> API endpoints on controllers on a completely separate L2 network (segment
>>> vlan/bridge) not present on any other nodes than controllers.
>>> Thanks.
>>>
>>> On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <
>>> adide...@mirantis.com> wrote:
>>>
 Hi folks,

 we had to revert those changes [0] since it's impossible to propery
 handle two different netconfig tasks for multi-role nodes. So everything
 stays as it was before - we have single task 'netconfig' to configure
 network for all roles and you don't need to change anything in your
 plugins. Sorry for inconvenience.

 Our current plan for fixing network idempotency is to keep one task but
 change 'cross-depends' parameter to yaql_exp. This will allow us to use
 single 'netconfig' task for all roles but at the same time we'll be able to
 properly order it: netconfig on non-controllers will be executed only
 aftetr 'virtual_ips' task.

 Regards,
 Alex

 [0] https://review.openstack.org/#/c/320530/


 On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <
 adide...@mirantis.com> wrote:

> Hi all,
>
> please be aware that now we have two netconfig tasks (in Fuel 9.0+):
>
> - netconfig-controller - executed on controllers only
> - netconfig - executed on all other nodes
>
> puppet manifest is the same, but tasks are different. We had to do
> this [0] in order to fix network idempotency issues [1].
>
> So if you have 'netconfig' requirements in your plugin's tasks, please
> make sure to add 'netconfig-controller' as well, to work properly on
> controllers.
>
> Regards,
> Alex
>
> [0] https://bugs.launchpad.net/fuel/+bug/1541309
> [1]
> https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z
>



 __
 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


>>>
>>>
>>> --
>>> Adam Heczko
>>> Security Engineer @ Mirantis Inc.
>>>
>>>
>>> __
>>> 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
>>
>>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __
> 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] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Adam Heczko
Thanks Alex, will experiment with it once again although AFAIR it doesn't
solve thing I'd like to do.
I'll come later to you in case of any questions.


On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko 
wrote:

> Hey Adam,
>
> in Fuel we have the following option (checkbox) on Network Setting tab:
>
> Assign public network to all nodes
> When disabled, public network will be assigned to controllers only
>
> So if you uncheck it (by default it's unchecked) then public network and
> 'br-ex' will exist on controllers only. Other nodes won't even have
> "Public" network on node interface configuration UI.
>
> Regards,
> Alex
>
> On Wed, May 25, 2016 at 9:43 AM, Adam Heczko  wrote:
>
>> Hello Alex,
>> I have a question about the proposed changes.
>> Is it possible to introduce new vlan and associated bridge only for
>> controllers?
>> I think about DMZ use case and possibility to expose public IPs/VIP and
>> API endpoints on controllers on a completely separate L2 network (segment
>> vlan/bridge) not present on any other nodes than controllers.
>> Thanks.
>>
>> On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko > > wrote:
>>
>>> Hi folks,
>>>
>>> we had to revert those changes [0] since it's impossible to propery
>>> handle two different netconfig tasks for multi-role nodes. So everything
>>> stays as it was before - we have single task 'netconfig' to configure
>>> network for all roles and you don't need to change anything in your
>>> plugins. Sorry for inconvenience.
>>>
>>> Our current plan for fixing network idempotency is to keep one task but
>>> change 'cross-depends' parameter to yaql_exp. This will allow us to use
>>> single 'netconfig' task for all roles but at the same time we'll be able to
>>> properly order it: netconfig on non-controllers will be executed only
>>> aftetr 'virtual_ips' task.
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://review.openstack.org/#/c/320530/
>>>
>>>
>>> On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <
>>> adide...@mirantis.com> wrote:
>>>
 Hi all,

 please be aware that now we have two netconfig tasks (in Fuel 9.0+):

 - netconfig-controller - executed on controllers only
 - netconfig - executed on all other nodes

 puppet manifest is the same, but tasks are different. We had to do this
 [0] in order to fix network idempotency issues [1].

 So if you have 'netconfig' requirements in your plugin's tasks, please
 make sure to add 'netconfig-controller' as well, to work properly on
 controllers.

 Regards,
 Alex

 [0] https://bugs.launchpad.net/fuel/+bug/1541309
 [1]
 https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z

>>>
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Adam Heczko
>> Security Engineer @ Mirantis Inc.
>>
>> __
>> 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
>
>


-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
__
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] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Aleksandr Didenko
Hey Adam,

in Fuel we have the following option (checkbox) on Network Setting tab:

Assign public network to all nodes
When disabled, public network will be assigned to controllers only

So if you uncheck it (by default it's unchecked) then public network and
'br-ex' will exist on controllers only. Other nodes won't even have
"Public" network on node interface configuration UI.

Regards,
Alex

On Wed, May 25, 2016 at 9:43 AM, Adam Heczko  wrote:

> Hello Alex,
> I have a question about the proposed changes.
> Is it possible to introduce new vlan and associated bridge only for
> controllers?
> I think about DMZ use case and possibility to expose public IPs/VIP and
> API endpoints on controllers on a completely separate L2 network (segment
> vlan/bridge) not present on any other nodes than controllers.
> Thanks.
>
> On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko 
> wrote:
>
>> Hi folks,
>>
>> we had to revert those changes [0] since it's impossible to propery
>> handle two different netconfig tasks for multi-role nodes. So everything
>> stays as it was before - we have single task 'netconfig' to configure
>> network for all roles and you don't need to change anything in your
>> plugins. Sorry for inconvenience.
>>
>> Our current plan for fixing network idempotency is to keep one task but
>> change 'cross-depends' parameter to yaql_exp. This will allow us to use
>> single 'netconfig' task for all roles but at the same time we'll be able to
>> properly order it: netconfig on non-controllers will be executed only
>> aftetr 'virtual_ips' task.
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/#/c/320530/
>>
>>
>> On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko > > wrote:
>>
>>> Hi all,
>>>
>>> please be aware that now we have two netconfig tasks (in Fuel 9.0+):
>>>
>>> - netconfig-controller - executed on controllers only
>>> - netconfig - executed on all other nodes
>>>
>>> puppet manifest is the same, but tasks are different. We had to do this
>>> [0] in order to fix network idempotency issues [1].
>>>
>>> So if you have 'netconfig' requirements in your plugin's tasks, please
>>> make sure to add 'netconfig-controller' as well, to work properly on
>>> controllers.
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://bugs.launchpad.net/fuel/+bug/1541309
>>> [1]
>>> https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z
>>>
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __
> 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] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Adam Heczko
Hello Alex,
I have a question about the proposed changes.
Is it possible to introduce new vlan and associated bridge only for
controllers?
I think about DMZ use case and possibility to expose public IPs/VIP and API
endpoints on controllers on a completely separate L2 network (segment
vlan/bridge) not present on any other nodes than controllers.
Thanks.

On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko 
wrote:

> Hi folks,
>
> we had to revert those changes [0] since it's impossible to propery handle
> two different netconfig tasks for multi-role nodes. So everything stays as
> it was before - we have single task 'netconfig' to configure network for
> all roles and you don't need to change anything in your plugins. Sorry for
> inconvenience.
>
> Our current plan for fixing network idempotency is to keep one task but
> change 'cross-depends' parameter to yaql_exp. This will allow us to use
> single 'netconfig' task for all roles but at the same time we'll be able to
> properly order it: netconfig on non-controllers will be executed only
> aftetr 'virtual_ips' task.
>
> Regards,
> Alex
>
> [0] https://review.openstack.org/#/c/320530/
>
>
> On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko 
> wrote:
>
>> Hi all,
>>
>> please be aware that now we have two netconfig tasks (in Fuel 9.0+):
>>
>> - netconfig-controller - executed on controllers only
>> - netconfig - executed on all other nodes
>>
>> puppet manifest is the same, but tasks are different. We had to do this
>> [0] in order to fix network idempotency issues [1].
>>
>> So if you have 'netconfig' requirements in your plugin's tasks, please
>> make sure to add 'netconfig-controller' as well, to work properly on
>> controllers.
>>
>> Regards,
>> Alex
>>
>> [0] https://bugs.launchpad.net/fuel/+bug/1541309
>> [1]
>> https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z
>>
>
>
> __
> 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
>
>


-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
__
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] [Fuel] [Plugins] Netconfig tasks changes

2016-05-25 Thread Aleksandr Didenko
Hi folks,

we had to revert those changes [0] since it's impossible to propery handle
two different netconfig tasks for multi-role nodes. So everything stays as
it was before - we have single task 'netconfig' to configure network for
all roles and you don't need to change anything in your plugins. Sorry for
inconvenience.

Our current plan for fixing network idempotency is to keep one task but
change 'cross-depends' parameter to yaql_exp. This will allow us to use
single 'netconfig' task for all roles but at the same time we'll be able to
properly order it: netconfig on non-controllers will be executed only
aftetr 'virtual_ips' task.

Regards,
Alex

[0] https://review.openstack.org/#/c/320530/


On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko 
wrote:

> Hi all,
>
> please be aware that now we have two netconfig tasks (in Fuel 9.0+):
>
> - netconfig-controller - executed on controllers only
> - netconfig - executed on all other nodes
>
> puppet manifest is the same, but tasks are different. We had to do this
> [0] in order to fix network idempotency issues [1].
>
> So if you have 'netconfig' requirements in your plugin's tasks, please
> make sure to add 'netconfig-controller' as well, to work properly on
> controllers.
>
> Regards,
> Alex
>
> [0] https://bugs.launchpad.net/fuel/+bug/1541309
> [1]
> https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z
>
__
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] [Fuel] [Plugins] Netconfig tasks changes

2016-05-19 Thread Aleksandr Didenko
Hi all,

please be aware that now we have two netconfig tasks (in Fuel 9.0+):

- netconfig-controller - executed on controllers only
- netconfig - executed on all other nodes

puppet manifest is the same, but tasks are different. We had to do this [0]
in order to fix network idempotency issues [1].

So if you have 'netconfig' requirements in your plugin's tasks, please make
sure to add 'netconfig-controller' as well, to work properly on controllers.

Regards,
Alex

[0] https://bugs.launchpad.net/fuel/+bug/1541309
[1]
https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z
__
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