Re: [Openstack-operators] [openstack-dev] [OpenStack-Ansible] Mitaka Upgrade
Hi Wade, sorry for the late reply most of us have been traveling / afk for a bit for the summit. Regarding Liberty > Mitaka upgrades there are a few issues that we need to work out before we have a supported upgrade process. Most notably we need to address: * https://bugs.launchpad.net/openstack-ansible/+bug/1577245 * https://bugs.launchpad.net/openstack-ansible/+bug/1568029 * https://bugs.launchpad.net/openstack-ansible/+bug/1574019 * https://bugs.launchpad.net/openstack-ansible/+bug/1574303 It's likely if you hand fix these items you should be all taken care of. That said, work will be in full swing in the next week or so to get upgrades 100% squared away and there may be some other things that need be addressed before we'd say they're fully supported. As for the RTFM part, it's not RTFM at all. We generally give our releases a bit of time to stabilize before announcing to the world how "wonderful our upgrade process is". Sadly, the issues you've found are a product of us not having worked everything out yet. We do have some documentation regarding the minor upgrade process as outlined here: [0] as well as other operational documentation that can be found here: [1]. Also if you're interested in working on the upgrades we'd love to have a chat regarding all of the things you've run into so that we can automate them away. I'd recommend joining in on the #openstack-ansible IRC channel and potentially raising issues on launchpad [2] for things we've not yet thought of to work on. As for what you've done thus far, it seems like a sensible approach. The playbook execution should drop new code into place and start/restart all of the services. However the straggler process may have been related to this issue [ https://bugs.launchpad.net/openstack-ansible/+bug/1577245 ] if you can look through that and the other issues mentioned earlier we'd appreciate the feedback. Sorry for the TL;DR I hope you're well. Ping us if you have questions. [0] - http://docs.openstack.org/developer/openstack-ansible/install-guide/app-minorupgrade.html [1] - http://docs.openstack.org/developer/openstack-ansible/install-guide/#operations [2] - https://bugs.launchpad.net/openstack-ansible/ -- Kevin Carter IRC: cloudnull From: Wade Holler <wade.hol...@gmail.com> Sent: Thursday, April 28, 2016 11:33 AM To: OpenStack Operators; OpenStack Development Mailing List (not for usage questions) Subject: [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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] openstack-ansible virt_type=lxc
Hello, On 11/18/2015 08:02 PM, Wade Holler wrote: > Just a little help needed. > on trusty > > > using openstack-ansible ( allinone ) > changed user_variables nova_virt_type to lxc > re-run os-nova-install > > Something else I need to do? > I've not played with the LXC hypervisor type in a long while however I remember the lxc option was not able to select a specific cpu type which the OSA project defaults to "host-type". So to correct this, you'll also want to set the following using the config_template options for nova.conf within your user_variables.yml file. nova_nova_conf_overrides: libvirt: cpu_mode: None cpu_model: None Once set you'll rerun the os-nova-install.yml play to reconfigure your hypervisor. > When launching an instance I get the no hosts found. > And in nova-conductor log I get the CPU model error > > 2015-11-18 20:16:40.041 3139 ERROR nova.scheduler.utils > [req-3323b36a-cfe3-46b1-b3b7-cb606c77fda8 > 37f9aa000df343d4ad1090a3d8330d67 25158527007e4a1c95a6a4b0c214576e - - -] > [instance: 0868a44b-79ab-419c-abcb-97a61831d309] Error from last host: > ubu1 (node ubu1): [u'Traceback (most recent call last):\n', u' File > "/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/compute/manager.py", > line 1903, in _do_build_and_run_instance\n filter_properties)\n', u' > File > "/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/compute/manager.py", > line 2063, in _build_and_run_instance\n instance_uuid=instance.uuid, > reason=six.text_type(e))\n', u"RescheduledException: Build of instance > 0868a44b-79ab-419c-abcb-97a61831d309 was re-scheduled: Config requested > an explicit CPU model, but the current libvirt hypervisor 'lxc' does not > support selecting CPU models\n"] > > Thanks! > Wade > Also make sure your images are LXC compatible. There are some steps outlined here [0] which may be of use to you. cheers. [0] - https://ask.openstack.org/en/question/14401/ubuntu-image-for-libvirt_typelxc/ -- Kevin Carter IRC: cloudnull ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [openstack-ansible] Fedora/CentOS/other Support
I don't believe we should have a class system in the OS's that we choose to support. If we're going to bring in a new OS I think we should first bring it in using non-voting jobs however once all of the bits have been finalized the supported OS should be able to pass the same sets of tests as everything else. Now, we may run into various applications that may not be compatible or available on different distros, which is fine, but in that case we should call out the deficiencies marking a specific job as non-voting until we can see about resolving the issues. I would like to avoid creating second class operating systems within OSA if at all possible. -- Kevin Carter IRC: cloudnull On 11/19/2015 09:21 AM, Major Hayden wrote: > On 11/18/2015 04:19 AM, Jesse Pretorius wrote: >> The current community has done some research into appropriate patterns to >> use and has a general idea of how to do it - but in order to actually >> execute there need to be enough people who commit to actually maintaining >> the work once it's done. We don't want to carry the extra code if we don't >> also pick up extra contributors to maintain the code. > > Should there be a concept of primary and secondary operating systems > supported by openstack-ansible? I'm thinking something similar to the tiers > of hypervisors in OpenStack where some are tested heavily with gating while > others have a lighter amount of testing. > > We might be able to have something along the lines of: > >* Primary OS: Used in gate checks, heavily tested >* Secondary OS: Not used in gate checks, lightly tested >* Tertiary OS: Support in WIP state, not tested > > -- > Major Hayden > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] OSAD for RHEL
-- Kevin Carter Racker, Developer, Hacker @ The Rackspace Private Cloud. From: Adam Young ayo...@redhat.com Sent: Tuesday, July 14, 2015 10:59 AM To: Kevin Carter; Kris G. Lindgren; John Dewey Cc: openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] OSAD for RHEL On 07/10/2015 02:25 PM, Kevin Carter wrote: To be clear the present OSAD project really has no intention to bring package based installations of OpenStack. We'd certainly not reject the idea and wouldn't mind having an implementation spec for it but all of our current tooling and design principles have been based on the fact that we've move away from distro packages and on to upstream source as it pertains to OpenStack. The system as it stands today creates an internal repository of built wheels for your environment and all of the OpenStack services are installed within LXC containers, where possible and it makes sense. The installation of these bits comes from the internal wheel repository and uses pip and all of the pre / post config happens within the Ansible playbooks. I understand your frustration with the packaging approach. For a first approximation, getting the code for OpenStack/Python operations out of Pip makes sense. Ideally, we would be able to support both approaches. Red Hat would not support a pip based install, but I am sure some Centos base users would be happy with pip. We had the same general discussion around devstack. One issue that will become a problem, for users of RedHat specifically, is the fact that RedHat has no LXC container templates (at least none that are publicly available) and even if someone were to make an official RedHat container template there'd be issues with the containers being able to connect to the satellite servers as well as other potential license problems. I'd leave the issues with getting blessed RHEL LXC support to Red Hat. Making something that works for CentOS with publically available LXC containers there would be more what I expect from OSAD upstream. What about Fedora support? It seems to me that we would be far more likely to have something supportable with Fedora that could then be backported to CentOS? I've done some experimenting with a RedHat 7.1 hosts and CentOS 7 containers and things seem to work OK but I'd not say that I have really put a lot of effort into it. That said, if its something that you'd all like to work on I'd be happy to help out to make it all go. Sounds good. I'll give it a try after the Keystone Midcycle. -- Kevin Carter From: Adam Young ayo...@redhat.commailto:ayo...@redhat.com Sent: Thursday, July 9, 2015 11:32 AM To: Kris G. Lindgren; John Dewey Cc: openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] OSAD for RHEL On 07/09/2015 02:16 AM, Kris G. Lindgren wrote: Does OSP support running each service in an LXC container as well? What about nova-cells? How does it handle people who need to carry local changes? What is the upgrade path like with OSP? So, ignoring the Hypervisor for the moment, there is no reason that the rest of the controllers can't run in separate Containers. I think a container based deployment would be fantastic. venv is not really sufficient, as the system level binaries can still conflict (MysQL and LDAP both require system libraries for Keystone, for example) From an Ansible perspective; we need to be able to share the HTTPD instance for Keystone and Apache, and getting that right will solve most of the issues deploying in a secure manner. Putting Them on separate hosts or containers should be a degenerate case, and thus be supported, too. Asking, because in Philly the general consensus, I fel,t was people want to move away from the current system level package stuff and move towards: venv's, lightweight packages, containers. The only reason that was brought up to keep packages around was to solve the non-python lib stuff and using a depsolver (yum/apt) that doesn't suck (pip). So I am pretty sure my wants are inline with what other people in the community are either already doing or moving towards. ___ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. From: John Dewey j...@dewey.wsmailto:j...@dewey.ws Date: Wednesday, July 8, 2015 at 11:43 PM To: Kris G. Lindgren klindg...@godaddy.commailto:klindg...@godaddy.com Cc: Adam Young ayo...@redhat.commailto:ayo...@redhat.com, openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] OSAD for RHEL This would not be acceptable for those running OSP. On Wednesday, July 8, 2015 at 10:12 PM, Kris G. Lindgren wrote: I should be more clear. My current thought
Re: [Openstack-operators] OSAD for RHEL
No opposition at all for adding in additional OS support. IMO it would be great in terms of support-ability and deployment perspectives. If you've not already checkout the #openstack-ansible channel and ping us if you have any questions. -- Kevin Carter IRC: cloudnull From: Abel Lopez alopg...@gmail.com Sent: Tuesday, July 7, 2015 4:38 PM To: openstack-oper. Subject: [Openstack-operators] OSAD for RHEL Hey everyone, I've started looking at osad, and I like much of the direction it takes. I'm pretty interested in developing it to run on RHEL, I just wanted to check if anyone would be -2 opposed to that before I spend cycles on it. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ansible Playbook for OpenStack (juno)
@Hamza if you get around to looking into the os-ansible-deployment project ?please consider joining our IRC channel on freenode at #openstack-ansible there almost always someone online and we'd be happy help you get started with the project. If you're just browsing, we have some installation documentation online that you have read through here: http://osad.readthedocs.org/en/latest/ Take care. -- Kevin Carter From: achi hara h16m...@gmail.com Sent: Sunday, July 5, 2015 10:14 AM To: Leslie-Alexandre DENIS Cc: openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] Ansible Playbook for OpenStack (juno) Hi Leslie Alexandre Thank you for providing me with the two links. i will try to use the second one. Regards, Hamza 2015-07-04 23:57 GMT+01:00 Leslie-Alexandre DENIS cont...@ladenis.frmailto:cont...@ladenis.fr: Hello, The best sources for that would be : - https://github.com/stackforge/os-ansible-deployment - https://github.com/blueboxgroup/ursula Actually these are well written and very modular, you probably don't really need all of the complexity for a standard deployment but at least you can start from that. Regards, Le 05/07/2015 00:40, achi hara a écrit : Hi everyone, I would like to deploy OpenStack (Juno release) using Ansible. could you please provide me with the playbooks for this purpose ? Your assistance is greatly appreciated. Sincerely Hamza ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.orgmailto:OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.orgmailto:OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [os-ansible-deployment] new features needing reviewers
Hello all, The os-ansible-deployment/OpenStack-Ansible project is gearing up for a couple feature drops and looking for reviews from interested people within the greater deployer/operator/dev community to ensure that we're developing the features/support people are looking for. Ceilometer: This review[0] completes the ceilometer blueprint[1] which adds support for ceilometer throughout the stack. While the change doesn't bring with it a salable mongodb deployment the solution does add ceilometer to OSAD as a first class capability and is tested using mongodb via our gate scripts. That said, if anyone knows of or has an Ansible solution for deploying, managing, and scaling mongodb we'd love to review, contribute, and pull it in as an external dependency when deploying Ceilometer with OSAD. Ceph: This review[2] adds ceph support for the various OpenStack service that can consume ceph. This is not a way to deploy a ceph infrastructure using Ansible, for that we're still recommending the upstream ceph playbooks/roles[3]. Additionally, this is not implementing ceph as a replacement to swift. These reviews are presently targeted at master which is gating on upstream liberty but we're intending to bring these changes into our kilo branch, which is tracking upstream kilo, to be released with the 11.1.0 tag and is scheduled to drop in the next few weeks[4]. We have lots of new goodness coming for 11.1.0 but these two features are largish so we'd appreciate some additional feedback/reviews. If you have some time and are interested in the OSAD project, we'd love to hear from you. -- Kevin Carter [0] https://review.openstack.org/#/c/173067/ [1] https://github.com/stackforge/os-ansible-deployment-specs/blob/master/specs/kilo/implement-ceilometer.rst [2] https://review.openstack.org/#/c/181957/ [3] https://github.com/ceph/ceph-ansible [4] https://launchpad.net/openstack-ansible/+milestone/11.1.0 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [os-ansible-deployment] Changes in the os-ansible-deployment project
Hello all, Over the past few weeks the os-ansible-deployment team has been working on getting the repository (https://github.com/stackforge/os-ansible-deployment) into a more community friendly state. For anyone who’s look at the project in the past and thought it was too Rackspace specific I’m here to announce that we’ve fixed that. The project has been De-Rackspace’d and Genericized while maintaining the reference architecture and intent. As of today, we’ve fully excised all of Rackspace Private Cloud specific roles and playbooks and have converted the remaining roles and playbooks into ones using Ansible best practices. We still have a lot of work to do but the project is growing in capability and scale and we’re eager to begin working more with the greater OpenStack community on what we think will be an asset to Operators and Developers alike. If you have an interest in Ansible, LXC containers, and/or deployments from source we’d love to have you join our community. Weekly meetings: https://wiki.openstack.org/wiki/Meetings/openstack-ansible IRC channel: #openstack-ansible Thank you again to everyone who’s contributed so far and we look forward to seeing you online. — Kevin signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [openstack-operators][os-ansible-deployment] Meeting Announcement.
Hi everyone, The os-ansible-deployment” project on stackforge is progressing and we’ve formalized our weekly meetings. If you’re interested in the project we’d love for you to drop by. For more information on our upcoming meetings please have a look here: https://wiki.openstack.org/wiki/Meetings/openstack-ansible”. Thanks and have a great week. — Kevin signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Announcing the openstack ansible deployment repo
Hello all, The RCBOPS team at Rackspace has developed a repository of Ansible roles, playbooks, scripts, and libraries to deploy Openstack inside containers for production use. We’ve been running this deployment for a while now, and at the last OpenStack summit we discussed moving the repo into Stackforge as a community project. Today, I’m happy to announce that the os-ansible-deployment repo is online within Stackforge. This project is a work in progress and we welcome anyone who’s interested in contributing. This project includes: * Ansible playbooks for deployment and orchestration of infrastructure resources. * Isolation of services using LXC containers. * Software deployed from source using python wheels. Where to find us: * IRC: #openstack-ansible * Launchpad: https://launchpad.net/openstack-ansible * Meetings: #openstack-ansible IRC channel every Tuesday at 14:30 UTC. (The meeting schedule is not fully formalized and may be subject to change.) * Code: https://github.com/stackforge/os-ansible-deployment Thanks and we hope to see you in the channel. — Kevin signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] Announcing the openstack ansible deployment repo
Hey John, We too ran into the same issue with iSCSI and after a lot of digging and chasing red-hearings we found that the cinder-volume service wasn’t the cause of the issues, it was iscsiadm login” that caused the problem and it was happening from within the nova-compute container. If we weren’t running cinder there were no issues with nova-compute running vm’s from within a container however once we attempted to attach a volume to a running VM iscsiadm would simply refuse to initiate. We followed up on an existing upstream bug regarding the issues but its gotten little traction at present: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855”. In testing we’ve found that if we give the compute container the raw device instead of using a bridge on a veth type interface we didn’t see the same issues however doing that was less than ideal so we opted to simply leave compute nodes as physical hosts. From within the playbooks we can set any service to run on bare metal as the “container” type so that’s what we’ve done with nova-compute but hopefully sometime soon-ish well be able to move nova-compute back into a container, assuming the upstream bugs are fixed. I’d love to chat some more on this or anything else, hit me up anytime; I’m @cloudnull in the channel. — Kevin On Dec 10, 2014, at 19:01, John Griffith john.griffi...@gmail.com wrote: On Wed, Dec 10, 2014 at 3:16 PM, Kevin Carter kevin.car...@rackspace.com wrote: Hello all, The RCBOPS team at Rackspace has developed a repository of Ansible roles, playbooks, scripts, and libraries to deploy Openstack inside containers for production use. We’ve been running this deployment for a while now, and at the last OpenStack summit we discussed moving the repo into Stackforge as a community project. Today, I’m happy to announce that the os-ansible-deployment repo is online within Stackforge. This project is a work in progress and we welcome anyone who’s interested in contributing. This project includes: * Ansible playbooks for deployment and orchestration of infrastructure resources. * Isolation of services using LXC containers. * Software deployed from source using python wheels. Where to find us: * IRC: #openstack-ansible * Launchpad: https://launchpad.net/openstack-ansible * Meetings: #openstack-ansible IRC channel every Tuesday at 14:30 UTC. (The meeting schedule is not fully formalized and may be subject to change.) * Code: https://github.com/stackforge/os-ansible-deployment Thanks and we hope to see you in the channel. — Kevin ___ OpenStack-dev mailing list openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hey Kevin, Really cool! I have some questions though, I've been trying to do this exact sort of thing on my own with Cinder but can't get iscsi daemon running in a container. In fact I run into a few weird networking problems that I haven't sorted, but the storage piece seems to be a big stumbling point for me even when I cut some of the extra stuff I was trying to do with devstack out of it. Anyway, are you saying that this enables running the reference LVM impl c-vol service in a container as well? I'd love to hear/see more and play around with this. Thanks, John ___ OpenStack-dev mailing list openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
