[openstack-dev] [kolla-ansible] dns_interface, inv

[vladislav . belogrudov]

Hi,

in multinode inventory I see that both haproxy and l3 agents run on 
network nodes. Does it mean that network nodes need two public 
interfaces - one for external VIP and another (unassigned) for external 
bridge? Will it work without conflicts?


Another question, designate-mdns runs on network nodes while others 
including designate-backend-bind - on controllers. Would it be better to 
run *bind on network node to facilitate easier external connectivity? I 
mean requirement for dns_interface, in other words, why not to make 
dns_interface == external one?


Thanks,
Vladislav




__
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] [kolla-ansible] Configure OpenStack services to use Rabbit HA queues

[vladislav . belogrudov]

thanks Jeffrey


On 05/05/2018 03:03 AM, Jeffrey Zhang wrote:

Hi vladispay,

I guess you are talking rabbit_ha_queues options. It is already marked 
as deprecated[0].


    cfg.BoolOpt('rabbit_ha_queues',
                default=False,
deprecated_group='DEFAULT',
                help='Try to use HA queues in RabbitMQ (x-ha-policy: 
all). '

                'If you change this option, you must wipe the RabbitMQ '
                'database. In RabbitMQ 3.0, queue mirroring is no longer '
                'controlled by the x-ha-policy argument when declaring a '
                'queue. If you just want to make sure that all queues 
(except '
                'those with auto-generated names) are mirrored across 
all '

                'nodes, run: '
                """\"rabbitmqctl set_policy HA '^(?!amq\.).*' """
                """'{"ha-mode": "all"}' \""""),

In kolla, we configure a global ha-mode policy through its 
definition.json file in rabbitmq, please check[1]


[0] 
https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_rabbit.py#L165-L176 
<https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_rabbit.py#L165-L176>
[1] 
https://github.com/openstack/kolla-ansible/blob/d2d9c6622888416ad2e748706fd237f8588e993a/ansible/roles/rabbitmq/templates/definitions.json.j2#L20 
<https://github.com/openstack/kolla-ansible/blob/d2d9c6622888416ad2e748706fd237f8588e993a/ansible/roles/rabbitmq/templates/definitions.json.j2#L20>


On Sat, May 5, 2018 at 12:58 AM, <vladislav.belogru...@oracle.com 
<mailto:vladislav.belogru...@oracle.com>> wrote:


Hi,

is there a reason we don't configure services for rabbitmq ha
queues like it is suggested in [0] ?
Rabbitmq itself has ha policy 'on' via one of its templates.

Thanks,
Vladislav Belogrudov

[0]
https://docs.openstack.org/ha-guide/shared-messaging.html#rabbitmq-services

<https://docs.openstack.org/ha-guide/shared-messaging.html#rabbitmq-services>

__
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
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>




--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me <http://xcodest.me/>


__
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

[openstack-dev] [kolla-ansible] Configure OpenStack services to use Rabbit HA queues

[vladislav . belogrudov]

Hi,

is there a reason we don't configure services for rabbitmq ha queues 
like it is suggested in [0] ?

Rabbitmq itself has ha policy 'on' via one of its templates.

Thanks,
Vladislav Belogrudov

[0] 
https://docs.openstack.org/ha-guide/shared-messaging.html#rabbitmq-services


__
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] [kolla] Policy regarding template customisation

[vladislav . belogrudov]

may be we could move those specific options / templates to sample 
overrides? Operators would move necessary pieces back to 
/etc/kolla/config . Just thinking of config plug-ins / third-party 
supported things.


Thanks,
Vlad

On 01/30/2018 01:46 PM, Paul Bourke wrote:
So I think everyone is in agreement that it should be option 2. I'm 
leaning towards this also but I'm wondering how much of this makes 
things easier for us as developers rather than operators.


How committed this are we in practice? For example, if we take 
nova.conf[0], if we follow option 2, theoretically all alternate 
hypervisor options (vmware/xen/nova-fake) etc. should come out and be 
left to override files. As should options templating options such as 
metadata_workers, listen ports, etc. globals.yml could probably be 
half the size it currently is. But if we go this route how many 
operators will stick with kolla? Maybe it won't be a big deal, the 
issue currently is the line is blurred on what gets templated and what 
doesn't.


On 30/01/18 01:04, Michał Jastrzębski wrote:

Hey,

So I'm also for option 2. There was big discussion in Atlanta about
"how hard it is to keep configs up to date and remove deprecated
options". merge_config makes it easier for us to handle this. With
amount of services we support I don't think we have enough time to
keep tabs on every config change across OpenStack.

On 29 January 2018 at 08:03, Steven Dake (stdake)  
wrote:

Agree, the “why” of this policy is stated here:

https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html 





Paul, I think your corrective actions sound good.  Perhaps we should 
also

reword “essential” to some other word that is more lenient.



Cheers

-steve



From: Jeffrey Zhang 
Reply-To: "OpenStack Development Mailing List (not for usage 
questions)"


Date: Monday, January 29, 2018 at 7:14 AM
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [kolla] Policy regarding template 
customisation




Thank Paul for pointing this out.



for me, I prefer to consist with 2)



There are thousands of configuration in OpenStack, it is hard for 
Kolla to


add every key/value pair in playbooks. Currently, the merge_config 
is a more


better solutions.









On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke 
 wrote:


Hi all,

I'd like to revisit our policy of not templating everything in
kolla-ansible's template files. This is a policy that was set in 
place very
early on in kolla-ansible's development, but I'm concerned we 
haven't been

very consistent with it. This leads to confusion for contributors and
operators - "should I template this and submit a patch, or do I need to
start using my own config files?".

The docs[0] are currently clear:

"The Kolla upstream community does not want to place key/value pairs 
in the
Ansible playbook configuration options that are not essential to 
obtaining a

functional deployment."

In practice though our templates contain many options that are not
necessary, and plenty of patches have merged that while very useful to
operators, are not necessary to an 'out of the box' deployment.

So I'd like us to revisit the questions:

1) Is kolla-ansible attempting to be a 'batteries included' tool, which
caters to operators via key/value config options?

2) Or, is it to be a solid reference implementation, where any 
degree of

customisation implies a clear 'bring your own configs' type policy.

If 1), then we should potentially:

* Update ours docs to remove the referenced paragraph
* Look at reorganising files like globals.yml into something more
maintainable.

If 2),

* We should make it clear to reviewers that patches templating 
options that

are non essential should not be accepted.
* Encourage patches to strip down existing config files to an absolute
minimum.
* Make this policy more clear in docs / templates to avoid 
frustration on

the part of operators.

Thoughts?

Thanks,
-Paul

[0]
https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization 



__ 


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





--

Regards,

Jeffrey Zhang

Blog: http://xcodest.me


__ 


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 

[openstack-dev] [cinder]

[vladislav . belogrudov]

Hi,

I'm testing multinode cluster with several cinder-volume instances. The 
latter are configured with iSCSI storage (ZFSSA). To enable HA of 
cinder-volume I had to specify 'host' option, otherwise volumes will be 
bound to a specific host (only good for LVM driver). This works so far 
but I am concerned about reported issues like race conditions:


https://bugzilla.redhat.com/show_bug.cgi?id=1193229

Is Active / Passive requirement for non-local (iSCSI-like) backends 
still valid? I also see 'cluster' option for A/A which still is 'not 
supported':


https://docs.openstack.org/cinder/pike/sample_config.html

Thanks,
Vladislav Belogrudov



__
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] [neutron] multiple vlan provider and tenant networks at the same time?

[vladislav . belogrudov]

Hi,

I wonder how it is possible to setup multiple network interfaces / 
bridge mappings for VLAN tenants and providers at the same time. E.g. in 
case of 1 VLAN network for tenant and 1 external VLAN how should neutron 
bridge mapping work? User interface does not allow to specify the mapping.


Example: 2 external VLAN interfaces and 2 tenant ones. In this case 
neutron configuration would be:


[ml2_type_vlan]
network_vlan_ranges = 
provider0,provider1,tenant-vlan2:200:299,tenant-vlan3:300:399


[ovs]
bridge_mappings = 
provider0:br-ext0,provider1:br-ext1,tenant-vlan2:br-vlan2,tenant-vlan3:br-vlan3


How can neutron decide on choosing correct vlan mapping for tenant? Will 
it try to pick provider0 if normal user creates a tenant network?


Thanks,
Vladislav

PS. Similar question could not be answered in [openstack]


__
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