Re: [openstack-dev] [openstack-ansible] Proposing Mohammed Naser as core reviewer
+2! On Thu, Apr 26, 2018 at 10:20 AM, Carter, Kevin wrote: > +2 from me! > > > -- > > Kevin Carter > IRC: Cloudnull > > On Wed, Apr 25, 2018 at 4:06 AM, Markos Chandras wrote: >> >> On 24/04/18 16:05, Jean-Philippe Evrard wrote: >> > Hi everyone, >> > >> > I’d like to propose Mohammed Naser [1] as a core reviewer for >> > OpenStack-Ansible. >> > >> >> +2 >> >> -- >> markos >> >> SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton >> HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg >> >> __ >> 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 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] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata
We have used aggregate based scheduler filters since deploying our cloud in Kilo. This explains the unpredictable scheduling we have seen since upgrading to Ocata. Before this post, was there some indication I missed that these filters can no longer be used? Even now reading the Ocata release notes[1] or checking the filter scheduler docs[2] I cannot find any indication that AggregateCoreFilter, AggregateRamFilter, and AggregateDiskFilter are useless in Ocata+. If I missed something I'd like to know where it is so I can avoid that mistake again! Just to make sure I understand correctly, given this list of filters we used in Newton: AggregateInstanceExtraSpecsFilter,AggregateNumInstancesFilter,AggregateCoreFilter,AggregateRamFilter,RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter I should remove AggregateCoreFilter, AggregateRamFilter, and RamFilter from the list because they are no longer useful, and replace them with the appropriate nova.conf settings instead, correct? What about AggregateInstanceExtraSpecsFilter and AggregateNumInstancesFilter? Do these still work? Thanks Logan [1] https://docs.openstack.org/releasenotes/nova/ocata.html [2] https://docs.openstack.org/ocata/config-reference/compute/schedulers.html On Wed, Jan 17, 2018 at 7:57 AM, Sylvain Bauza wrote: > > > On Wed, Jan 17, 2018 at 2:22 PM, Jay Pipes wrote: >> >> On 01/16/2018 08:19 PM, Zhenyu Zheng wrote: >>> >>> Thanks for the info, so it seems we are not going to implement aggregate >>> overcommit ratio in placement at least in the near future? >> >> >> As @edleafe alluded to, we will not be adding functionality to the >> placement service to associate an overcommit ratio with an aggregate. This >> was/is buggy functionality that we do not wish to bring forward into the >> placement modeling system. >> >> Reasons the current functionality is poorly architected and buggy >> (mentioned in @melwitt's footnote): >> >> 1) If a nova-compute service's CONF.cpu_allocation_ratio is different from >> the host aggregate's cpu_allocation_ratio metadata value, which value should >> be considered by the AggregateCoreFilter filter? >> >> 2) If a nova-compute service is associated with multiple host aggregates, >> and those aggregates contain different values for their cpu_allocation_ratio >> metadata value, which one should be used by the AggregateCoreFilter? >> >> The bottom line for me is that the AggregateCoreFilter has been used as a >> crutch to solve a **configuration management problem**. >> >> Instead of the configuration management system (Puppet, etc) setting >> nova-compute service CONF.cpu_allocation_ratio options *correctly*, having >> the admin set the HostAggregate metadata cpu_allocation_ratio value is >> error-prone for the reasons listed above. >> > > Well, the main cause why people started to use AggregateCoreFilter and > others is because pre-Newton, it was litterally impossible to assign > different allocation ratios in between computes except if you were grouping > them in aggregates and using those filters. > Now that ratios are per-compute, there is no need to keep those filters > except if you don't touch computes nova.conf's so that it defaults to the > scheduler ones. The crazy usecase would be like "I have 1000+ computes and I > just want to apply specific ratios to only one or two" but then, I'd second > Jay and say "Config management is the solution to your problem". > > >> >> Incidentally, this same design flaw is the reason that availability zones >> are so poorly defined in Nova. There is actually no such thing as an >> availability zone in Nova. Instead, an AZ is merely a metadata tag (or a >> CONF option! :( ) that may or may not exist against a host aggregate. >> There's lots of spaghetti in Nova due to the decision to use host aggregate >> metadata for availability zone information, which should have always been >> the domain of a **configuration management system** to set. [*] >> > > IMHO, not exactly the root cause why we have spaghetti code for AZs. I > rather like the idea to see an availability zone as just a user-visible > aggregate, because it makes things simple to understand. > What the spaghetti code is due to is because the transitive relationship > between an aggregate, a compute and an instance is misunderstood and we > introduced the notion of "instance AZ" which is a fool. Instances shouldn't > have a field saying "here is my AZ", it should rather be a flag saying "what > the user wanted as AZ ? (None being a choice) " > > >> In the Placement service, we have the concept of aggregates, too. However, >> in Placement, an aggregate (note: not "host aggregate") is merely a grouping >> mechanism for resource providers. Placement aggregates do not have any >> attributes themselves -- they merely represent the relationship between >> resource providers. Placement aggregates suffer from ne
Re: [openstack-dev] [openstack-ansible][security] To firewalld, or not to firewalld
Ferm DSL is nice and featureful. There's a pretty sophisticated debops ferm role at [1] allowing for pretty sophisticated rule definitions [2]. Structurally I think the most important thing is having the ability to define rules in layers based on host_vars, group_vars, etc. and have them blended together by the firewall role using a weighting system. You can get really fancy with the rules definitions as shown by the rules.d template in debops-ferm [3]. My question now is what does ferm give us that iptables-save templating does not? Writing ferm configuration can differ pretty substantially from iptables-save syntax, and we add another language dependency (perl) in the process. I think for ferm to make sense, we should be able to argue pretty convincingly that there's some major advantages over laying down a consolidated templated iptables-save file. IMO we can have all of the same sophistication this way and expose it in a very nice interface through ansible vars. [1] https://github.com/debops/ansible-ferm [2] https://docs.debops.org/en/latest/ansible/roles/ansible-ferm/docs/ [3] https://github.com/debops/ansible-ferm/tree/master/templates/etc/ferm On Wed, Aug 2, 2017 at 3:47 PM, Major Hayden wrote: > On 08/02/2017 03:57 AM, Mark Goddard wrote: >> The solution we built used a conf.d/ mechanism layered on top of iptables. >> An advantage of this approach is that operators or co-resident software >> stacks could add their own rules to the firewall. AFAIK, this is not >> generally possible when using iptables-save/restore as it relies on a single >> configuration file which must be 'owned' by something - in this case >> presumably OSA. >> >> I'm not suggesting that you reimplement the solution I've described, but it >> does outline one benefit of firewalld - OSA would not need to entirely own >> the firewall configuration. > > Thanks for the feedback! I'm leaning away from firewalld now and looking at > something a little simpler with iptables. > > During a recent IRC meeting someone brought up ferm[0]. They have several > examples, but the workstation[1] one makes some sense. It would be fairly > easy to template the ferm DSL files. > > [0] http://ferm.foo-projects.org/ > [1] http://ferm.foo-projects.org/download/examples/webserver.ferm > > -- > Major Hayden > > __ > 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] [OpenStack-Ansible] Proposing Markos Chandras for osa-core
+1 Awesome work on the suse support, but also on improving the nuts and bolts of our tests and everything else during that process. On Tue, Jul 18, 2017 at 7:57 AM, Major Hayden wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 07/18/2017 04:23 AM, Andy McCrae wrote: >> Following on from last week's meeting I'd like to propose Markos (hwoarang) >> for OSA core. >> >> Markos has done a lot of good reviews and commits over an extended period of >> time, and has shown interest in the project as a whole. (Not to mention the >> addition of SUSE support) >> >> We already have quite a few +1's from the meeting itself, but opening up to >> everybody who wasn't available at the meeting! > > +1 here! Anyone that offers to help with the ansible-hardening role is solid > in my book. ;) > > Markos has been doing great work and he's automated quite a few things that > we used to push around manually. SUSE support has been building out *really* > quickly, too. > > - -- > Major Hayden > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJZbgXFAAoJEHNwUeDBAR+x0b0P/jYbzThAhWkmb0qbdzQcHYoc > 9Tgx6eymEU8HEs+wC74+r1JBAfUF32thymwM1ToZv7RT+3w0KT3ArEadEmo2+BSz > TtNCsg4adCHVQHdPnHeFor0jT9PHXYlMzRwfU4UHEjFkcDBX4iHNvUIYkOp/NSy2 > OAZE3YmYxPRUbw87VeIOi2lLhhbdoJJWlFJbHRH4xY2jjl6Le6UjdVpgErhzHcaP > 3VhJI5mR4bKLhjrnJmgMVC6ECxZ4PDMa3uzfpJ+STWVzgOODk6FQ89AfcOTwbX8K > /m3aw6e9+KyiacrriK6xZJlTzBpWZyj17V9V6xb4hzHZMkSn0X0OJD0L6YYp1k+r > YBXB4kPFeX4KMoxpp5Xu0COu0cjLF3rqb0tZHsh0B8dDjYcXs+SY1QEoQyEvyX1q > 2kqbNS4+rg0uNO0ioddAG+mwJZ7oX+b3kHeJT6XLhkXgyLnBVXC9lCvbNrOJUuwa > HHcNj/Xxti1fZT51/TvtKM/ou1gdWPbW3NGAwp0+d5oEiy2mUnL/p1J8i1T1c3V/ > kA5zWcY9UX+WbArwmxRtoOIJn5CAOSccii8Uc2HCx89au7BBxtA3k7LNNWo9B2jF > S4KcWUZi7EnWyFOw4+VcW2OctCxKeEuO7yCxaW5ffrHeYl2GjXoKupPanvVMq/Pq > WphlU0lHsiNNTXrghFaw > =2Zxr > -END PGP SIGNATURE- > > __ > 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] [openstack-ansible][security] Rename openstack-ansible-security role?
On Wed, May 17, 2017 at 12:39 PM, Jesse Pretorius wrote: > On 5/17/17, 6:25 PM, "Major Hayden" wrote: > > 1) Should the openstack-ansible-security role be > renamed to alleviate confusion? > > Sure, I’ve long thought that the name is misleading. +1 definitely in favor of a rename > > 2) If it should be renamed, what's your suggestion? > > My uninspired suggestion is to make it something like > ‘ansible-host-security’. A quick google search for that only shows the > openstack-ansible-security role anyway. ( No amazing suggestions from me... ansible-host-security is fine, maybe ansible-security or ansible-hardening. Nothing you haven't already thought of I'm sure. __ 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] [Openstack] [Openstack-ansible] openstack ansible HA solution
Hello, Yes openstack-ansible does support deploying keepalived along with haproxy. The keepalived role is run just before the haproxy role in this playbook: https://github.com/openstack/openstack-ansible/blob/master/playbooks/haproxy-install.yml#L27-L31 You can see an example keepalived configuration in the prod config example of the OSA deployment guide: https://docs.openstack.org/project-deploy-guide/openstack-ansible/draft/app-config-prod.html#user-variables On Wed, Apr 26, 2017 at 3:32 AM, Liyuenan (Maxwell Li) wrote: > Hi, all > > > > I have some questions about OSA project. > > > > 1. OSA can install haproxy, but I can not found any other HA solution > in openstack-ansible-haproxy_server, like keepalived or pacemarker. So how > to making HAproxy high-available? > > 2. Could OSA support compute node high available? If my compute node > down, could the instance on this node move to other nodes? > > > > Thank you! > > > > Best Regards! > > Maxwell Li > > maxwelli.com > > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openst...@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/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
Re: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core reviewer
+1 awesome work on the CentOS support! And lots of helpful reviews on things not CentOS too. Thanks Marc Logan On Fri, Feb 3, 2017 at 7:52 AM, Jean-Philippe Evrard wrote: > Hello, > > > > Great! > > +1 > > > > Best regards, > > JP > > > > From: Jesse Pretorius > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Friday, 3 February 2017 at 13:33 > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core > reviewer > > > > Hi everyone, > > > > I’d like to propose Marc Gariepy [1] as a core reviewer for > OpenStack-Ansible. His tireless effort to get CentOS as a supported platform > in the last two cycles is getting very close to completion, and I feel that > it’s important that he’s able to safeguard this work and help grow the > maintenance community for it. > > > > [1] > http://stackalytics.com/?module=openstackansible-group&user_id=mgariepy&release=ocata&metric=person-day > > > > Best regards, > > > > Jesse > > IRC: odyssey4me > > > > > > Rackspace Limited is a company registered in England & Wales (company > registered number 03897010) whose registered office is at 5 Millington Road, > Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be > viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may > contain confidential or privileged information intended for the recipient. > Any dissemination, distribution or copying of the enclosed material is > prohibited. If you receive this transmission in error, please notify us > immediately by e-mail at ab...@rackspace.com and delete the original > message. Your cooperation is appreciated. > > > __ > 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] [openstack-ansible][openstack-ansible-plugins] error in rabbitmq installation , config template plugin
Hi Tomer,
I noticed you said you have _v2_config_template.py in your action
plugins path, but you should also have verify you have the
"config_template" in your library path: ie.
https://github.com/openstack/openstack-ansible-plugins/blob/master/library/config_template
On Thu, Nov 17, 2016 at 8:11 AM, Shtilman, Tomer (Nokia - IL)
wrote:
> Many thanks
>
> I was aware of the dependencies and download them all to
>
> /home/centos/ansible-installation/roles/dependencies
>
>
>
> [centos@ansible-tests-tshtilma dependencies]$ ls
>
> apt_package_pinning lxc_container_create lxc_hosts openstack_hosts
> pip_install
>
>
>
> also my test playbook was taken from the examples so its almost identical
>
>
>
> Thanks
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: Jesse Pretorius [mailto:]
> Sent: יום ה 17 נובמבר 2016 15:45
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [openstack-ansible][openstack-ansible-plugins]
> error in rabbitmq installation , config template plugin
>
>
>
> The error you’re seeing is because that role has dependencies which can’t be
> resolved.
>
>
>
> The deps are here:
>
> https://github.com/openstack/openstack-ansible-rabbitmq_server/blob/stable/newton/meta/main.yml#L35
>
>
>
> The roles are mostly designed to be re-usable without the integrated
> repository, but to do so you’ll need to inspect the role tests to see what
> it needs to work:
>
>
>
> Role requirements, to resolve the meta deps:
>
> https://github.com/openstack/openstack-ansible-rabbitmq_server/blob/stable/newton/tests/ansible-role-requirements.yml
>
>
>
> An example inventory, playbook, etc is all here:
>
> https://github.com/openstack/openstack-ansible-rabbitmq_server/tree/stable/newton/tests
>
>
>
> If you get stuck, feel free to join us in #openstack-ansible in IRC on
> Freenode.
>
>
>
> HTH,
>
>
>
> Jesse
>
> IRC: odyssey4me
>
>
>
> From: "Shtilman, Tomer (Nokia - IL)"
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: Thursday, November 17, 2016 at 1:33 PM
> To: "openstack-dev@lists.openstack.org"
> Subject: [openstack-dev] [openstack-ansible][openstack-ansible-plugins]
> error in rabbitmq installation , config template plugin
>
>
>
> Hi All
>
> I am relatively new to Ansible, trying to run a playbook installing rabbit
> server https://github.com/openstack/openstack-ansible-rabbitmq_server (all
> stable/newton)
>
>
>
> - name: Install RabbitMQ server
>
> hosts: rabbitmq_all
>
> user: root
>
> roles:
>
> - { role: "rabbitmq_server", tags: [ "rabbitmq-server" ] }
>
> vars:
>
> rabbitmq_cookie_token: secrete
>
>
>
>
>
> I get an error:
>
>
>
> statically included:
> /home/centos/ansible-installation/roles/dependencies/pip_install/tasks/configure.yml
>
> ERROR! no action detected in task. This often indicates a misspelled module
> name, or incorrect module path.
>
>
>
> The error appears to have been in
> '/home/centos/ansible-installation/roles/dependencies/pip_install/tasks/configure.yml':
> line 40, column 3, but may
>
> be elsewhere in the file depending on the exact syntax problem.
>
>
>
> The offending line appears to be:
>
>
>
>
>
> - name: Drop pip global config(s)
>
> ^ here
>
>
>
>
>
> The task is :
>
> - name: Drop pip global config(s)
>
> config_template:
>
> src: "global.conf.j2"
>
> ……
>
>
>
>
>
>
>
> config_template task is coming from
> https://github.com/openstack/openstack-ansible-plugins/blob/master/action/_v2_config_template.py
> and cloned locally
>
> also I have set the action_plugins =
> /home/centos/openstack-ansible-plugins:/home/centos/openstack-ansible-plugins/action
>
> from a bit of debugging its look like the the path is scanned
>
>
>
> Any ideas will be appreciated
>
> Tomer
>
>
>
>
>
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington Road,
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may
> contain confidential or privileged information intended for the recipient.
> Any dissemination, distribution or copying of the enclosed material is
> prohibited. If you receive this transmission in error, please notify us
> immediately by e-mail at ab...@rackspace.com and delete the original
> message. Your cooperation is appreciated.
>
>
> __
> 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/lis
