Re: [openstack-dev] [ansible] One or more undefined variables: 'dict object' has no attribute 'bridge'
Hi Mark, I haven't reviewed your configs yet but if "bridge" is a valid ansible inventory attribute , then this error is usually caused by trying to reference a host that ansible didn't check in on yet / gather facts on. At least this is what is has been in my brief experience. For example if I wanted to reference all hosts in a "webservers" ansible group to build a haproxy config but that playbook didn't apply to the "webservers" group them their facts have not been collected. Just a thought. Cheers Wade On Sat, Dec 12, 2015 at 9:34 AM Mark Korondi wrote: > Hi all, > > Trying to set up openstack-ansible, but stuck on this point: > > > TASK: [set local_ip fact (is_metal)] > * > > ... > > fatal: [os-compute-1] => One or more undefined variables: 'dict object' > has no > > attribute 'bridge' > > ... > > One or more undefined variables: 'dict object' has no attribute 'bridge' > > These are my configs: > - http://paste.openstack.org/show/481739/ > (openstack_user_config.yml) > - http://paste.openstack.org/show/481740/ > (/etc/network/interfaces on compute host called `os-compute-1`) > > I set up the eth12 veth pair interface also on the compute host as you can > see. > `ifup-ifdown` works without any problems reported. > > > Why is it reporting an undefined bridge variable? Any ideas on my config > is well > appreciated. > > Mark > > __ > 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]
Just a little help probably. On CentOS 7.2 I tried to follow the quickstart very closely. [root@cpn00012 kolla]# python --version Python 2.7.5 [root@cpn00012 kolla]# pip --version pip 8.0.2 from /usr/lib/python2.7/site-packages (python 2.7) tools/build.py fails like this: tools/build.py INFO:__main__:Found the docker image folder at /root/kolla/docker Traceback (most recent call last): File "tools/build.py", line 708, in main() File "tools/build.py", line 688, in main for x in six.moves.range(conf.threads): AttributeError: '_MovedItems' object has no attribute 'range' I'm sure it is something easy. Could someone please help. Very interested in this project. Best Regards, Wade __ 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]
Thank you Steve. I will clean out the yum Python / everything and place the emphasis on pip. Then when i can fully engage I'll hop on freenode. Thank you again!!! On Sat, Feb 20, 2016 at 9:09 AM Steven Dake (stdake) wrote: > Wade, > > My guess is you have six installed via both pip and RPM and they are > different versions. If you want help, join us on irc on #freenode, and we > can get you going. Its much faster then debugging over a mailing list. > > Regards > -steve > > > From: Wade Holler > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Saturday, February 20, 2016 at 6:52 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [kolla] > > Just a little help probably. > > On CentOS 7.2 > I tried to follow the quickstart very closely. > > [root@cpn00012 kolla]# python --version > > Python 2.7.5 > > [root@cpn00012 kolla]# pip --version > > pip 8.0.2 from /usr/lib/python2.7/site-packages (python 2.7) > > > tools/build.py fails like this: > > tools/build.py > > INFO:__main__:Found the docker image folder at /root/kolla/docker > > Traceback (most recent call last): > > File "tools/build.py", line 708, in > > main() > > File "tools/build.py", line 688, in main > > for x in six.moves.range(conf.threads): > > AttributeError: '_MovedItems' object has no attribute 'range' > > I'm sure it is something easy. Could someone please help. Very > interested in this project. > > > Best Regards, > Wade > > > > __ > 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] [kolla]
removed multiple python packages via yum and pip uninstall. that made it past it. now hitting a mariadb error early in the deploy If anyone can help I would really appreciate it. Im on #kolla @ wadeholler http://pastebin.com/83jL0ege On Sat, Feb 20, 2016 at 9:45 AM Wade Holler wrote: > Thank you Steve. I will clean out the yum Python / everything and place > the emphasis on pip. Then when i can fully engage I'll hop on freenode. > Thank you again!!! > On Sat, Feb 20, 2016 at 9:09 AM Steven Dake (stdake) > wrote: > >> Wade, >> >> My guess is you have six installed via both pip and RPM and they are >> different versions. If you want help, join us on irc on #freenode, and we >> can get you going. Its much faster then debugging over a mailing list. >> >> Regards >> -steve >> >> >> From: Wade Holler >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> >> Date: Saturday, February 20, 2016 at 6:52 AM >> To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> Subject: [openstack-dev] [kolla] >> >> Just a little help probably. >> >> On CentOS 7.2 >> I tried to follow the quickstart very closely. >> >> [root@cpn00012 kolla]# python --version >> >> Python 2.7.5 >> >> [root@cpn00012 kolla]# pip --version >> >> pip 8.0.2 from /usr/lib/python2.7/site-packages (python 2.7) >> >> >> tools/build.py fails like this: >> >> tools/build.py >> >> INFO:__main__:Found the docker image folder at /root/kolla/docker >> >> Traceback (most recent call last): >> >> File "tools/build.py", line 708, in >> >> main() >> >> File "tools/build.py", line 688, in main >> >> for x in six.moves.range(conf.threads): >> >> AttributeError: '_MovedItems' object has no attribute 'range' >> >> I'm sure it is something easy. Could someone please help. Very >> interested in this project. >> >> >> Best Regards, >> Wade >> >> >> >> __ >> 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] [Openstack-operators] [OpenStack-Ansible] Mitaka Upgrade
Hi All, If this is RTFM please point me there and I apologize. If not: We are testing the Liberty to Mitaka transition with OSAD. Could someone please advise if these were the correct general steps. osad multinode (VMs/instances inside a osad cloud) built with latest 12.X liberty osad 1. save off config files: openstack_user_config.yml, user_variables,yml, ...hostname..., inventory, etc. 2. rm -rf /etc/openstack_deploy; rm -rf /opt/openstack-ansible 3. git clone -b stable/mitaka 4. copy config files back in place 5. ./scripts/bootstrap-ansible.sh 6. openstack-ansible setup-everything.yml That is the process we ran and it appears to have went well after adding the "-e rabbit_upgrade=true" flag. Only straggler process that I found so far was a neutron-ns-metadata-proxy that was still running 12.X liberty code. restarted the container and it didn't start again, but the 13.X mitaka version is running ( and was before shutdown ). Is this the correct upgrade process or are there other steps / approaches that should be taken ? Best Regards, Wade __ 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] When to purge the DB, and when not to purge the DB?
+1 "As part of the normal execution of the service playbooks" w/ user_variable to turn it on/off of course; whether it defaults to on or off is really designers choice. Some production clouds will have the playbooks ran against them frequently, others not so much. On Sat, Jul 2, 2016 at 7:43 AM Jesse Pretorius < jesse.pretor...@rackspace.co.uk> wrote: > On 7/1/16, 8:48 PM, "Ian Cordasco" wrote: > > > > >-Original Message- > >From: Jesse Pretorius > > > >> In a recent conversation on the Operators list [1] there was a > discussion about purging > >> archived data in the database. It would seem to me an important step in > maintaining an > >> environment which should be done from time to time and perhaps at the > very least prior > >> to a major upgrade. > >> > >> What’re the thoughts on how often this should be done? Should we > include it as an opt-in > >> step, or an opt-out step? > >> > >> [1] > http://lists.openstack.org/pipermail/openstack-operators/2016-June/010813.html > > > >Is OpenStack-Ansible now going to get into the minutae of operating > >the entire cloud? I was under the impression that it left the easy > >things to the operators (e.g., deciding when and how to purge the > >database) while taking care of the things that are less obvious > >(setting up OpenStack, and interacting with the database directly to > >only set up things for the services). > > That’s a good question which betrays the fact that I phrased my question > poorly. :) > > The question is whether we should do something like this: > > 1) As part of the normal execution of the service playbooks; > 2) As part of the automated major upgrade (i.e. The step is not optional); > 3) As part of the manual major upgrade (i.e. The step is optional); > 4) Never. > > If never, it might be useful for our community to curate a few bits of > operations tooling to automated this sort of thing on demand. The tooling > can be placed into the Ops repository [1] if this is done. > > [1] https://github.com/openstack/openstack-ansible-ops > > > 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
