[Openstack-operators] [all][kolla][rdo] Collaboration with Kolla for the RDO test days
Hi ! For those who might be unfamiliar with the RDO [1] community project: we hang out in #rdo, we don't bite and we build vanilla OpenStack packages. These packages are what allows you to leverage one of the deployment projects such as TripleO, PackStack or Kolla to deploy on CentOS or RHEL. The RDO community collaborates with these deployment projects by providing trunk and stable packages in order to let them develop and test against the latest and the greatest of OpenStack. RDO test days typically happen around a week after an upstream milestone has been reached [2]. The purpose is to get everyone together in #rdo: developers, users, operators, maintainers -- and test not just RDO but OpenStack itself as installed by the different deployment projects. We tried something new at our last test day [3] and it worked out great. Instead of encouraging participants to install their own cloud for testing things, we supplied a cloud of our own... a bit like a limited duration TryStack [4]. This lets users without the operational knowledge, time or hardware to install an OpenStack environment to see what's coming in the upcoming release of OpenStack and get the feedback loop going ahead of the release. We used Packstack for the last deployment and invited Packstack cores to deploy, operate and troubleshoot the installation for the duration of the test days. The idea is to rotate between the different deployment projects to give every interested project a chance to participate. Last week, we reached out to Kolla to see if they would be interested in participating in our next RDO test days [5] around February 8th. We supply the bare metal hardware and their core contributors get to deploy and operate a cloud with real users and developers poking around. All around, this is a great opportunity to get feedback for RDO, Kolla and OpenStack. We'll be advertising the event a bit more as the test days draw closer but until then, I thought it was worthwhile to share some context for this new thing we're doing. Let me know if you have any questions ! Thanks, [1]: https://www.rdoproject.org/ [2]: https://www.rdoproject.org/testday/ [3]: https://dmsimard.com/2017/11/29/come-try-a-real-openstack-queens-deployment/ [4]: http://trystack.org/ [5]: http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-01-24-16.00.log.html David Moreau Simard Senior Software Engineer | OpenStack RDO dmsimard = [irc, github, twitter] ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Fwd: [rdo-users] Queens Milestone 2 test day, December 14th, 15th
Hi openstack-operators ! I'm sharing this in case anyone is interested in participating in the upcoming RDO community test day. We're trying something new to get more people interested in testing the latest and the greatest of OpenStack's upcoming release. Feel free to ask me if you have any questions ! David Moreau Simard Senior Software Engineer | OpenStack RDO dmsimard = [irc, github, twitter] -- Forwarded message -- From: Rich Bowen <rbo...@redhat.com> Date: Mon, Dec 4, 2017 at 4:43 PM Subject: [rdo-users] Queens Milestone 2 test day, December 14th, 15th To: us...@lists.rdoproject.org Join us next Thursday and Friday as we test Queens Milestone 2 - the next version of OpenStack. http://rdoproject.org/testday/queens/milestone2/ This time, we're doing something a little different. For those of you who don't have the time, patience, or hardware to spin up your own OpenStack cloud, we'll have one ready for you. You can just log in, try it out, try your work loads, try to break things. We're hoping, with this change, to open test day to a wider audience of users and operators. If you're interested in participating in this test, and seeing what's coming in February, read this blog post [1] and sign up here [2] for your login credentials. Please also consider amplifying this invitation by following @RDOCommunity on Twitter, and retweeting the invitations to test day, as well as by sending this message to other relevant mailing lists. Thanks! [1] https://dmsimard.com/2017/11/29/come-try-a-real-openstack-qu eens-deployment/ [2] https://etherpad.openstack.org/p/rdo-queens-m2-cloud -- Rich Bowen - rbo...@redhat.com http://rdoproject.org @RDOCommunity ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] RDO at the OpenStack PTG
Hi! The RDO community project [1] provides RPM OpenStack packages for deploying on RHEL and CentOS. RDO is analogous to Ubuntu Cloud Archive (UCA) which provides OpenStack packages for installing on Ubuntu. I'm no marketing or sales guy, I'm part of the RDO engineering team in charge of building, packaging, testing and shipping RDO. If you happen to be at the PTG and would like to chat about RDO, please let me know off-thread so we can set aside some time. I'm always excited to talk with users and operators ! Thanks and see you there ! [1]: http://rdoproject.org David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [upgrades][skip-level][leapfrog] - RFC - Skipping releases when upgrading
I've mentioned this elsewhere but writing here for posterity... Making N to N+1 upgrades seamless and work well is already challenging today which is one of the reasons why people aren't upgrading in the first place. Making N to N+1 upgrades work as well as possible already puts a great strain on developers and resources, think about the testing and CI involved in making sure things really work. My opinion is that of upgrades were made out to be a simple, easy and seamless operation, it wouldn't be that much of a problem to upgrade from N to N+3 by upgrading from release to release (three times) until you've caught up. But then, if upgrades are awesome, maybe operators won't be lagging 3 releases behind anymore. David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Thu, May 25, 2017 at 9:55 PM, Carter, Kevin <ke...@cloudnull.com> wrote: > Hello Stackers, > > As I'm sure many of you know there was a talk about doing "skip-level"[0] > upgrades at the OpenStack Summit which quite a few folks were interested in. > Today many of the interested parties got together and talked about doing > more of this in a formalized capacity. Essentially we're looking for cloud > upgrades with the possibility of skipping releases, ideally enabling an N+3 > upgrade. In our opinion it would go a very long way to solving cloud > consumer and deployer problems it folks didn't have to deal with an upgrade > every six months. While we talked about various issues and some of the > current approaches being kicked around we wanted to field our general chat > to the rest of the community and request input from folks that may have > already fought such a beast. If you've taken on an adventure like this how > did you approach it? Did it work? Any known issues, gotchas, or things folks > should be generally aware of? > > > During our chat today we generally landed on an in-place upgrade with known > API service downtime and little (at least as little as possible) data plane > downtime. The process discussed was basically: > a1. Create utility "thing-a-me" (container, venv, etc) which contains the > required code to run a service through all of the required upgrades. > a2. Stop service(s). > a3. Run migration(s)/upgrade(s) for all releases using the utility > "thing-a-me". > a4. Repeat for all services. > > b1. Once all required migrations are complete run a deployment using the > target release. > b2. Ensure all services are restarted. > b3. Ensure cloud is functional. > b4. profit! > > Obviously, there's a lot of hand waving here but such a process is being > developed by the OpenStack-Ansible project[1]. Currently, the OSA tooling > will allow deployers to upgrade from Juno/Kilo to Newton using Ubuntu 14.04. > While this has worked in the lab, it's early in development (YMMV). Also, > the tooling is not very general purpose or portable outside of OSA but it > could serve as a guide or just a general talking point. Are there other > tools out there that solve for the multi-release upgrade? Are there any > folks that might want to share their expertise? Maybe a process outline that > worked? Best practices? Do folks believe tools are the right way to solve > this or would comprehensive upgrade documentation be better for the general > community? > > As most of the upgrade issues center around database migrations, we > discussed some of the potential pitfalls at length. One approach was to > roll-up all DB migrations into a single repository and run all upgrades for > a given project in one step. Another was to simply have mutliple python > virtual environments and just run in-line migrations from a version specific > venv (this is what the OSA tooling does). Does one way work better than the > other? Any thoughts on how this could be better? Would having N+2/3 > migrations addressable within the projects, even if they're not tested any > longer, be helpful? > > It was our general thought that folks would be interested in having the > ability to skip releases so we'd like to hear from the community to validate > our thinking. Additionally, we'd like to get more minds together and see if > folks are wanting to work on such an initiative, even if this turns into > nothing more than a co-op/channel where we can "phone a friend". Would it be > good to try and secure some PTG space to work on this? Should we try and > create working group going? > > If you've made it this far, please forgive my stream of consciousness. I'm > trying to ask a lot of questions and distill long form conversation(s) into > as little text as possible all without writing a novel. With that said, I > hope this finds you well, I look forward
Re: [Openstack-operators] Migrating glance images to a new backend
Oh, hey, that's my blog. Happy to answer questions as much as my memory allows.. I haven't revisited this particular topic, it was a one-time thing for me. I would certainly hope for there to be a better way by now, almost two years later! Curious to see if other operators have any insight to share as my method was fairly hacked together. David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Mar 24, 2017 11:58 AM, "Massimo Sgaravatto" <massimo.sgarava...@gmail.com> wrote: Hi In our Mitaka cloud we are currently using Gluster as storage backend for Glance and Cinder. We are now starting the migration to ceph: the idea is then to dismiss gluster when we have done. I have a question concerning Glance. I have understood (or at least I hope so) how to add ceph as store backend for Glance so that new images will use ceph while the previously created ones on the file backend will be still usable. My question is how I can migrate the images from the file backend to ceph when I decide to dismiss the gluster based storage. The only documentation I found is this one: https://dmsimard.com/2015/07/18/migrating-glance-images-to- a-different-backend/ Could you please confirm that there aren't other better (simpler) approaches for such image migration ? Thanks, Massimo ___ 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] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0
Part of the issue here is that the CentOS team told us yesterday they were having technical difficulties signing and releasing the new 2.6.0 packages to the public mirrors. Yesterday around 6:30PM UTC they gave us an approximate ETA of 5 hours. I see this morning that it still seems problematic and I pinged them in order to let them know. We've definitely also seen glimpses of issues related to running qemu-kvm <2.6.0 paired with CentOS 7.3 so thanks for the clarifications. David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Dec 13, 2016 11:06 PM, "Steve Gordon" <sgor...@redhat.com> wrote: > - Original Message - > > From: "David Moreau Simard" <d...@redhat.com> > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-...@lists.openstack.org>, "OpenStack > > Operators" <openstack-operators@lists.openstack.org> > > Sent: Tuesday, December 13, 2016 6:13:12 PM > > Subject: [Openstack-operators] [all] Known issue with CentOS 7.3 and > qemu-kvm(-ev) 2.6.0 > > > > Hi, > > > > CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev > > was shipped as part of this release if you have the CentOS > > Virtualization SIG repositories enabled. > > Isn't the issue that the newer version of qemu-kvm-ev (2.6.0) *hasn't* > shipped yet? E.g. it's not in: > > http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/ > > Hence the mismatch is created because the CentOS repos contain Libvirt > 2.0.0 but not a matching qemu-kvm-ev build (yet). > > Thanks, > > Steve > > > If you're using RDO >= Newton, you will have this repository enabled. > > It was not yet enforced in the Mitaka release so you might or might > > not have it, depending on your deployment. > > Older releases of OpenStack may also be affected but they are not > > proactively tested anymore due to EOL. > > > > There is currently a known issue when using the following > > configuration in nova for compute: > > == > > virt_type=qemu > > cpu_mode=host-model > > == > > > > This combination will yield in failed attempts at creating instances > > and you will see errors like these in nova-compute.log [1] or the > > libvirt logs [2]. > > The problem boils down to libvirt trying to pass a cpu extension that > > is unknown to qemu: > > == > > qemu-kvm: CPU feature arat not found > > == > > > > There is a bugzilla [3] for this issue but in the meantime users are > > encouraged to work around the issue by setting "cpu_mode=none" if they > > are using the qemu (not KVM) hypervisor. > > Please note that Nova defaults the 'cpu_mode' parameter to > > 'host-model' [4] if 'cpu_mode' is not explicitely configured and > > 'virt_type' is 'qemu' so if you're running into this issue, you will > > need to explicitely configure it. > > > > [1]: > > http://logs.openstack.org/76/409476/4/check/gate-puppet- > openstack-integration-4-scenario003-tempest-centos-7/ > 8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832 > > [2]: > > http://logs.openstack.org/76/409476/4/check/gate-puppet- > openstack-integration-4-scenario003-tempest-centos-7/ > 8881991/logs/libvirt/qemu/instance-0001.txt.gz > > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617 > > [4]: > > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/ > libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411 > > > > David Moreau Simard > > Senior Software Engineer | Openstack RDO > > > > dmsimard = [irc, github, twitter] > > > > ___ > > 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
[Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0
Hi, CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev was shipped as part of this release if you have the CentOS Virtualization SIG repositories enabled. If you're using RDO >= Newton, you will have this repository enabled. It was not yet enforced in the Mitaka release so you might or might not have it, depending on your deployment. Older releases of OpenStack may also be affected but they are not proactively tested anymore due to EOL. There is currently a known issue when using the following configuration in nova for compute: == virt_type=qemu cpu_mode=host-model == This combination will yield in failed attempts at creating instances and you will see errors like these in nova-compute.log [1] or the libvirt logs [2]. The problem boils down to libvirt trying to pass a cpu extension that is unknown to qemu: == qemu-kvm: CPU feature arat not found == There is a bugzilla [3] for this issue but in the meantime users are encouraged to work around the issue by setting "cpu_mode=none" if they are using the qemu (not KVM) hypervisor. Please note that Nova defaults the 'cpu_mode' parameter to 'host-model' [4] if 'cpu_mode' is not explicitely configured and 'virt_type' is 'qemu' so if you're running into this issue, you will need to explicitely configure it. [1]: http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832 [2]: http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617 [4]: http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411 David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Fwd: [rdo-list] Getting ready for RDO on Centos 7.3
Hi openstack-operators, With the impending release of CentOS 7.3, derived out of RHEL 7.3, this can surely be of interest whether you're running from source or from RDO packages. You can see the full thread on rdo-list here [1]. [1]: https://www.redhat.com/archives/rdo-list/2016-November/msg00111.html David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] -- Forwarded message -- From: Alfredo Moralejo Alonso <amora...@redhat.com> Date: Fri, Nov 25, 2016 at 12:04 PM Subject: [rdo-list] Getting ready for RDO on Centos 7.3 To: rdo-list <rdo-l...@redhat.com> Hi, In the last days we've been running our RDO-CI pipelines using a pre-release of the incoming Centos 7.3 release. We'd like to share with the RDO community some issues we've being facing and some recommendations to be prepared for this new release: 1. package mariadb-libs-5.5.52 included in CentOS 7.3 conflicts wiht mariadb packages included in RDO repositories. Typically, this package may be in the OS base installation before starting OpenStack deployment, what can lead to errors while installing mariadb-server from RDO. To avoid this, update your system right after enabling RDO repositories in your servers and before starting OpenStack services deployment. 2. The versions of qemu-kvm-ev and openstack-selinux provided by VirtSIG and CloudSIG at 7.3 release will require other packages in CentOS 7.3. If you try to install them without updated repos enabled, you'll get some errors. The recommendation from RDO team is to move to Centos 7.3 based installations to deploy RDO as soon as possible after it's officially released. This will ensure you are using a configuration already tested in RDO CI. If this is not possible for any reason, make sure you have the official Centos 7 repos enabled and available in your server. This repo will provide requirements needed. By following these guidelines we expect a smooth transition to Centos 7.3 for RDO users. Don't hesitate to contact #rdo at freenode or this mail list for any question you may have. Best regards, Alfredo ___ rdo-list mailing list rdo-l...@redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscr...@redhat.com ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] If you are deploying with or against RDO, we'd like to hear from you
Hi Pieter, We are planning on doing a post on the RDO blog [1] of the aggregated (further anonymized if necessary) data once the survey is closed. The last question where we ask for your contact information will obviously not be published. [1]: https://www.rdoproject.org/blog/ David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Tue, Oct 18, 2016 at 11:56 AM, Kruithof Jr, Pieter <pieter.kruithof...@intel.com> wrote: > Hi David, > > Can you talk a bit about how you intend to share the results and/or data from > the survey? > > Thanks, > > Piet > > > On 10/18/16, 9:48 AM, "David Moreau Simard" <d...@redhat.com> wrote: > > Hi openstack-operators, > > We're currently gathering feedback from RDO users and operators with > the help of a very small and anonymous survey [1]. > > It's not very in-depth as we value your time and we all know filling > surveys is boring but it'd be very valuable to us. > > If you'd like to chat RDO more in details at the upcoming OpenStack > summit: what we're doing right, what we're doing wrong or even if you > have questions about either starting to use it or how to get > involved... > Feel free to get in touch with me or join us at the RDO community meetup > [2]. > > Thanks ! > > [1]: https://www.redhat.com/archives/rdo-list/2016-October/msg00128.html > [2]: > https://www.eventbrite.com/e/an-evening-of-ceph-and-rdo-tickets-28022550202 > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > ___ > 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
[Openstack-operators] If you are deploying with or against RDO, we'd like to hear from you
Hi openstack-operators, We're currently gathering feedback from RDO users and operators with the help of a very small and anonymous survey [1]. It's not very in-depth as we value your time and we all know filling surveys is boring but it'd be very valuable to us. If you'd like to chat RDO more in details at the upcoming OpenStack summit: what we're doing right, what we're doing wrong or even if you have questions about either starting to use it or how to get involved... Feel free to get in touch with me or join us at the RDO community meetup [2]. Thanks ! [1]: https://www.redhat.com/archives/rdo-list/2016-October/msg00128.html [2]: https://www.eventbrite.com/e/an-evening-of-ceph-and-rdo-tickets-28022550202 David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs
I realize just now that the repository setup instructions aren't on that wiki page. The package you want to install is "centos-release-qemu-ev". That'll setup the required repositories. David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Fri, Sep 30, 2016 at 3:04 PM, David Moreau Simard <d...@redhat.com> wrote: > If you are deploying on CentOS (with RDO?), you can enable the CentOS > Virtualization special interest group [1] repository. > > The repository contains qemu-kvm-ev >= 2.3 backported from RHEV. > It is recommended as the qemu-kvm version from base CentOS > repositories is not high enough and lacks some features (things like > snapshots, iirc). > > qemu-kvm >= 2.3 is actually a requirement in RDO >= Newton and we'll > bundle the CentOS virtualization SIG repository in our release > packages. > > [1]: https://wiki.centos.org/SpecialInterestGroup/Virtualization > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > > On Thu, Sep 29, 2016 at 5:00 AM, William Josefsson > <william.josef...@gmail.com> wrote: >> thanks everyone, I verified setting mem_stats_period_seconds = 0 as >> suggested by Corbin in nova.conf libvirt section, and then restarting >> openstack-nova-compute service and it works! >> >> While this seems to be a workable workaround I'm not sure what's the plans >> to permanently fix this in CentOS7.2? thx will >> >> >> >> On Wed, Sep 28, 2016 at 11:37 PM, Corbin Hendrickson >> <corbin.hendrick...@endurance.com> wrote: >>> >>> Oh you can read it in the bug thread, but I forgot to mention, if you put >>> in your nova.conf under the libvirt section mem_stats_period_seconds = 0, >>> and restart nova on the destination (although i'd say just do it on both) it >>> will no longer hit the bug. I tested this a couple weeks back with success. >>> >>> Corbin Hendrickson >>> Endurance Cloud Development Lead - Manager >>> Cell: 801-400-0464 >>> >>> On Wed, Sep 28, 2016 at 9:34 AM, Corbin Hendrickson >>> <corbin.hendrick...@endurance.com> wrote: >>>> >>>> It unfortunately is affecting virtually all of Redhat's latest qemu-kvm >>>> packages. The bug that was unintentionally introduced was done so in >>>> response to CVE-2016-5403 Qemu: virtio: unbounded memory allocation on >>>> host >>>> via guest leading to DoS. >>>> >>>> Late in the bug thread, they finally posted to a new bug created for the >>>> breaking of live migrate via Bug 1371943 - RHSA-2016-1756 breaks migration >>>> of instances. >>>> >>>> Based off their posts i've been following it's likely going to "hit the >>>> shelves" when RHEL 7.3 / CentOS 7.3 comes out. It does look like they are >>>> backporting it to all their versions of RHEL so that's good. >>>> >>>> But yes this does affect 2.3 as well. >>>> >>>> Corbin Hendrickson >>>> Endurance Cloud Development Lead - Manager >>>> Cell: 801-400-0464 >>>> >>>> On Wed, Sep 28, 2016 at 9:13 AM, Van Leeuwen, Robert >>>> <rovanleeu...@ebay.com> wrote: >>>>> >>>>> > There is a bug in the following: >>>>> >>>>> > >>>>> >>>>> > qemu-kvm-1.5.3-105.el7_2.7 >>>>> >>>>> > qemu-img-1.5.3-105.el7_2.7 >>>>> >>>>> > qemu-kvm-common-1.5.3-105.el7_2.7 >>>>> >>>>> >>>>> >>>>> You might be better of using the RHEV qemu packages >>>>> >>>>> They are more recent (2.3) and have more features compiled into them. >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Robert van Leeuwen >>>>> >>>>> >>>>> ___ >>>>> 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 >> ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Nova live-migration failing for RHEL7/CentOS7 VMs
If you are deploying on CentOS (with RDO?), you can enable the CentOS Virtualization special interest group [1] repository. The repository contains qemu-kvm-ev >= 2.3 backported from RHEV. It is recommended as the qemu-kvm version from base CentOS repositories is not high enough and lacks some features (things like snapshots, iirc). qemu-kvm >= 2.3 is actually a requirement in RDO >= Newton and we'll bundle the CentOS virtualization SIG repository in our release packages. [1]: https://wiki.centos.org/SpecialInterestGroup/Virtualization David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Thu, Sep 29, 2016 at 5:00 AM, William Josefsson <william.josef...@gmail.com> wrote: > thanks everyone, I verified setting mem_stats_period_seconds = 0 as > suggested by Corbin in nova.conf libvirt section, and then restarting > openstack-nova-compute service and it works! > > While this seems to be a workable workaround I'm not sure what's the plans > to permanently fix this in CentOS7.2? thx will > > > > On Wed, Sep 28, 2016 at 11:37 PM, Corbin Hendrickson > <corbin.hendrick...@endurance.com> wrote: >> >> Oh you can read it in the bug thread, but I forgot to mention, if you put >> in your nova.conf under the libvirt section mem_stats_period_seconds = 0, >> and restart nova on the destination (although i'd say just do it on both) it >> will no longer hit the bug. I tested this a couple weeks back with success. >> >> Corbin Hendrickson >> Endurance Cloud Development Lead - Manager >> Cell: 801-400-0464 >> >> On Wed, Sep 28, 2016 at 9:34 AM, Corbin Hendrickson >> <corbin.hendrick...@endurance.com> wrote: >>> >>> It unfortunately is affecting virtually all of Redhat's latest qemu-kvm >>> packages. The bug that was unintentionally introduced was done so in >>> response to CVE-2016-5403 Qemu: virtio: unbounded memory allocation on host >>> via guest leading to DoS. >>> >>> Late in the bug thread, they finally posted to a new bug created for the >>> breaking of live migrate via Bug 1371943 - RHSA-2016-1756 breaks migration >>> of instances. >>> >>> Based off their posts i've been following it's likely going to "hit the >>> shelves" when RHEL 7.3 / CentOS 7.3 comes out. It does look like they are >>> backporting it to all their versions of RHEL so that's good. >>> >>> But yes this does affect 2.3 as well. >>> >>> Corbin Hendrickson >>> Endurance Cloud Development Lead - Manager >>> Cell: 801-400-0464 >>> >>> On Wed, Sep 28, 2016 at 9:13 AM, Van Leeuwen, Robert >>> <rovanleeu...@ebay.com> wrote: >>>> >>>> > There is a bug in the following: >>>> >>>> > >>>> >>>> > qemu-kvm-1.5.3-105.el7_2.7 >>>> >>>> > qemu-img-1.5.3-105.el7_2.7 >>>> >>>> > qemu-kvm-common-1.5.3-105.el7_2.7 >>>> >>>> >>>> >>>> You might be better of using the RHEV qemu packages >>>> >>>> They are more recent (2.3) and have more features compiled into them. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Robert van Leeuwen >>>> >>>> >>>> ___ >>>> 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 > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [kolla] Decision to deprecate Fedora
For what it's worth, RDO does not currently test deployment on top of Fedora (since Liberty at the very latest).and we also no longer ship OpenStack Service/Server components to Fedora [1]. We don't see this changing in the short term. [1]: https://www.redhat.com/archives/rdo-list/2015-September/msg00090.html David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Tue, Sep 27, 2016 at 3:02 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > Hey folks, > > > > We are deprecating the fedora implementation in newton, and it will be > removed in Ocata. Reference: > > https://review.openstack.org/#/c/369184/ > > > > Since nobody seems to complain it is not working, it seems not worthwhile to > maintain it. At present the fedora implementation is broken. > > > > If you are currently using Kolla with Fedora (I don’t know how, it doesn’t > work) – the migration plan I’d recommend is switching to CentOS. > > > > Any objections? > > > > Regards > > -steve > > > ___ > 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] [puppet] [desginate] An update on the state of puppet-designate (and designate in RDO)
I drafted some tentative release notes that summarizes the work that has been done so far [1]. I asked input from #openstack-dns but would love if users could chime in on a deprecation currently in review [2]. This change also makes it so designate will stop maintaining a directory in /var/lib/designate/bind9. This directory and was introduced in puppet-designate in 2013 and doesn't seem relevant anymore according to upstream and designate documentation. [1]: http://docs-draft.openstack.org/04/338404/1/check/gate-puppet-designate-releasenotes/273e921//releasenotes/build/html/unreleased.html#id1 [2]: https://review.openstack.org/#/c/337951/ David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Wed, Jul 6, 2016 at 11:51 AM, David Moreau Simard <d...@redhat.com> wrote: > Thanks Matt, if you don't mind I might add you to some puppet reviews. > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > > On Tue, Jul 5, 2016 at 10:22 PM, Matt Fischer <m...@mattfischer.com> wrote: >> We're using Designate but still on Juno. We're running puppet from around >> then, summer of 2015. We'll likely try to upgrade to Mitaka at some point >> but Juno Designate "just works" so it's been low priority. Look forward to >> your efforts here. >> >> On Tue, Jul 5, 2016 at 7:47 PM, David Moreau Simard <d...@redhat.com> wrote: >>> >>> Hi ! >>> >>> tl;dr >>> puppet-designate is going under some significant updates to bring it >>> up to par right now. >>> While I will try to ensure it is well tested and backwards compatible, >>> things *could* break. Would like feedback. >>> >>> I cc'd -operators because I'm interested in knowing if there are any >>> users of puppet-designate right now: which distro and release of >>> OpenStack? >>> >>> I'm a RDO maintainer and I took interest in puppet-designate because >>> we did not have any proper test coverage for designate in RDO >>> packaging until now. >>> >>> The RDO community mostly relies on collaboration with installation and >>> deployment projects such as Puppet OpenStack to test our packaging. >>> We can, in turn, provide some level of guarantee that packages built >>> out of trunk branches (and eventually stable releases) should work. >>> The idea is to make puppet-designate work with RDO, then integrate it >>> in the puppet-openstack-integration CI scenarios and we can leverage >>> that in RDO CI afterwards. >>> >>> Both puppet-designate and designate RDO packaging were unfortunately >>> in quite a sad state after not being maintained very well and a lot of >>> work was required to even get basic tests to pass. >>> The good news is that it didn't work with RDO before and now it does, >>> for newton. >>> Testing coverage has been improved and will be improved even further >>> for both RDO and Ubuntu Cloud Archive. >>> >>> If you'd like to follow the progress of the work, the reviews are >>> tagged with the topic "designate-with-rdo" [1]. >>> >>> Let me know if you have any questions ! >>> >>> [1]: https://review.openstack.org/#/q/topic:designate-with-rdo >>> >>> David Moreau Simard >>> Senior Software Engineer | Openstack RDO >>> >>> dmsimard = [irc, github, twitter] >>> >>> ___ >>> 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] [puppet] [desginate] An update on the state of puppet-designate (and designate in RDO)
Thanks Matt, if you don't mind I might add you to some puppet reviews. David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Tue, Jul 5, 2016 at 10:22 PM, Matt Fischer <m...@mattfischer.com> wrote: > We're using Designate but still on Juno. We're running puppet from around > then, summer of 2015. We'll likely try to upgrade to Mitaka at some point > but Juno Designate "just works" so it's been low priority. Look forward to > your efforts here. > > On Tue, Jul 5, 2016 at 7:47 PM, David Moreau Simard <d...@redhat.com> wrote: >> >> Hi ! >> >> tl;dr >> puppet-designate is going under some significant updates to bring it >> up to par right now. >> While I will try to ensure it is well tested and backwards compatible, >> things *could* break. Would like feedback. >> >> I cc'd -operators because I'm interested in knowing if there are any >> users of puppet-designate right now: which distro and release of >> OpenStack? >> >> I'm a RDO maintainer and I took interest in puppet-designate because >> we did not have any proper test coverage for designate in RDO >> packaging until now. >> >> The RDO community mostly relies on collaboration with installation and >> deployment projects such as Puppet OpenStack to test our packaging. >> We can, in turn, provide some level of guarantee that packages built >> out of trunk branches (and eventually stable releases) should work. >> The idea is to make puppet-designate work with RDO, then integrate it >> in the puppet-openstack-integration CI scenarios and we can leverage >> that in RDO CI afterwards. >> >> Both puppet-designate and designate RDO packaging were unfortunately >> in quite a sad state after not being maintained very well and a lot of >> work was required to even get basic tests to pass. >> The good news is that it didn't work with RDO before and now it does, >> for newton. >> Testing coverage has been improved and will be improved even further >> for both RDO and Ubuntu Cloud Archive. >> >> If you'd like to follow the progress of the work, the reviews are >> tagged with the topic "designate-with-rdo" [1]. >> >> Let me know if you have any questions ! >> >> [1]: https://review.openstack.org/#/q/topic:designate-with-rdo >> >> David Moreau Simard >> Senior Software Engineer | Openstack RDO >> >> dmsimard = [irc, github, twitter] >> >> ___ >> 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
[Openstack-operators] [puppet] [desginate] An update on the state of puppet-designate (and designate in RDO)
Hi ! tl;dr puppet-designate is going under some significant updates to bring it up to par right now. While I will try to ensure it is well tested and backwards compatible, things *could* break. Would like feedback. I cc'd -operators because I'm interested in knowing if there are any users of puppet-designate right now: which distro and release of OpenStack? I'm a RDO maintainer and I took interest in puppet-designate because we did not have any proper test coverage for designate in RDO packaging until now. The RDO community mostly relies on collaboration with installation and deployment projects such as Puppet OpenStack to test our packaging. We can, in turn, provide some level of guarantee that packages built out of trunk branches (and eventually stable releases) should work. The idea is to make puppet-designate work with RDO, then integrate it in the puppet-openstack-integration CI scenarios and we can leverage that in RDO CI afterwards. Both puppet-designate and designate RDO packaging were unfortunately in quite a sad state after not being maintained very well and a lot of work was required to even get basic tests to pass. The good news is that it didn't work with RDO before and now it does, for newton. Testing coverage has been improved and will be improved even further for both RDO and Ubuntu Cloud Archive. If you'd like to follow the progress of the work, the reviews are tagged with the topic "designate-with-rdo" [1]. Let me know if you have any questions ! [1]: https://review.openstack.org/#/q/topic:designate-with-rdo David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] How to get instance name only by floating ip and then change it to hostname
It doesn't look like the --ip parameter searches through the floating
IPs, that's probably a UX expectation issue and improvement that could
be done to the CLI client.
Something like this should get you what you want:
openstack server set $(openstack server list -f value |awk
'/11.11.111.11/ {print $1}') --name newname
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Tue, Jun 7, 2016 at 11:19 AM, OpenStack Mailing List Archive
<cor...@gmail.com> wrote:
> Link: https://openstack.nimeyo.com/86809/?show=86809#q86809
> From: Wenqi <w...@redhat.com>
>
> Hi,
> What is the cli to get the instance name only and then change it to
> hostname?
> I know how to get the instance info table from private ip by below command:
> nova list --ip 11.11.111.11
> I just want the name and then use the below command to change it with
> hostname
> nova rename server name
>
>
> ___
> 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] Ceph puppet module
Hey Stuart, You might want to look at (and use, if you want) the built-in roles and profiles layer [1] which gives you a good idea of how the module is used. It leverages ceph::profile::params to pass values [2] to other classes such as ceph::profile::osd [3]. Another good place to look at how to use the module would be the integration tests [4]. Since the module is integration tested, this means we actually use the module to deploy a virtual Ceph cluster and we test that the cluster works - see for example the tests for ceph::profile::osd [4]. I'm dmsimard on #puppet-openstack and #openstack-operators if you need a hand to get this to work. This is still a relatively new module in comparison to the likes of puppet-nova and such. Feedback and contributions are appreciated! [1] https://github.com/stackforge/puppet-ceph/tree/master/manifests/profile [2] https://github.com/stackforge/puppet-ceph/blob/master/manifests/profile/params.pp [3] https://github.com/stackforge/puppet-ceph/blob/master/manifests/profile/osd.pp [4] https://github.com/stackforge/puppet-ceph/blob/master/spec/system/ceph_profile_osd_spec.rb -- David Moreau Simard From: Andrew Woodward xar...@gmail.commailto:xar...@gmail.com Date: Saturday, February 21, 2015 at 4:39 PM To: Stuart Fox stu...@demonware.netmailto:stu...@demonware.net Cc: openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org, puppet-openst...@puppetlabs.commailto:puppet-openst...@puppetlabs.com puppet-openst...@puppetlabs.commailto:puppet-openst...@puppetlabs.com Subject: Re: [Openstack-operators] Ceph puppet module [+puppet-openstack ml] Stuart, Please review the USECASES.md such as [1]. You should find usable examples there. If you are still having problems please reach out with a more detail about what you configuration you are attempting to deploy. The module authors can be found in #puppet-openstack and are usually lurking on the puppet-openstack mailing list (CC'd). [1]https://github.com/stackforge/puppet-ceph/blob/master/USECASES.md#i-want-to-operate-a-production-cluster On Sat, Feb 21, 2015 at 12:04 AM, Stuart Fox stu...@demonware.netmailto:stu...@demonware.net wrote: Hey all Im having a complete nightmare trying to get ceph deployed using the https://github.com/stackforge/puppet-ceph module. Scant documentation isn't helping my cause! Is anybody else using this module? Im attempting to deploy ceph as a cinder backend in Juno on Ubuntu 14.04 although I haven't gotten as far as integration yet. Does anyone have working example's I could look at? -- BR, Stuart ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.orgmailto:OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Andrew Mirantis Fuel community ambassador Ceph community ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] (no subject)
For monitoring, there seems to be a lot of buzz/interest about the new Monasca project (https://wiki.openstack.org/wiki/Monasca) but you're probably going to get as many different solutions are there are products. You can have a look at the etherpad from the Paris Ops summit session on monitoring to give you an idea: https://etherpad.openstack.org/p/kilo-summit-ops-monitoring We've found Shinken to be able to scale pretty well and cope without too much problems to the thousands of services we're throwing at it. We use Graphite for data collection and Grafana for data visualization. For logging, the Openstack Infra team uses the ELK stack (Elastic search, Logstash, Kibana) for collecting/aggregating/visualizing/searching logs: http://ci.openstack.org/logstash.html I'll let the other operators chime in on the security side of things. -- David Moreau Simard From: Zeeshan Ali Shah zas...@kth.semailto:zas...@kth.se Date: Monday, January 12, 2015 at 6:57 AM To: openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org Subject: [Openstack-operators] (no subject) Hi All, What is the suggestion to monitor (resource, security) of a large scale OS deployment. 1) For Resource : I tried Nagios and Zabbix they are good at certain extent but is there any other suggestion ? 2) For Security /logging etc, i am planning to use Ossec and Elastic search . any suggestion for here ? -- Regards Zeeshan Ali Shah System Administrator - PDC HPC PhD researcher (IT security) Kungliga Tekniska Hogskolan +46 8 790 9115 http://www.pdc.kth.se/members/zashah ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Windows license activation - How do you do it ?
Hi, I'm curious to see if other operators could share their experience involving Windows license activation in their Openstack environment. We use a Windows KMS server but it's proven to be a challenge to reliably only allow specific/authorized subnets to communicate with it across multiple regions. Thanks ! -- David Moreau Simard ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] EtherPad from the Friday morning session?
Otherwise all other etherpads can be found here: https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads#Ops -- David Moreau Simard On Nov 12, 2014, at 6:27 PM, Mathieu Gagné mga...@iweb.com wrote: On 2014-11-12 6:11 PM, Simon McCartney wrote: Does anybody have the URL for the EtherPad of notes from the Friday morning session on the white sofa? Did I also see Michael a few others start a project entry on wiki.openstack.org? I unfortunately didn't attend but I think this is the etherpad you are looking for: https://etherpad.openstack.org/p/kilo-summit-ops-opsprogram -- Mathieu ___ 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] Proposal for an 'Operations' project
As far as monitoring is concerned, we've just had a session at the Ops summit - etherpad: https://etherpad.openstack.org/p/kilo-summit-ops-monitoring Definitely lots of various initiatives regarding monitoring scripts/tools that could benefit from being centralized.. at a quick glance: - https://github.com/stackforge/monitoring-for-openstack - https://github.com/osops/tools-monitoring - https://github.com/sensu/sensu-community-plugins/tree/master/plugins/openstack - https://github.com/cirrax/openstack-nagios-plugins - http://packages.ubuntu.com/search?keywords=nagios-plugins-openstack My personal recommendation would be that we should focus on the stackforge repository. -- David Moreau Simard On Nov 6, 2014, at 12:20 PM, Michael Chapman wop...@gmail.com wrote: Hi Operators! I felt like OpenStack didn't have enough projects, so here's another one. During the summit I feel like I'm repeatedly having the same conversations with different groups about bespoke approaches to operational tasks, and wrapping these in a project might be a way to promote collaboration on them. Off the top of my head there's half a dozen things that might belong here: - Packaging tooling (spec files/fpm script/whatever) - (Ansible/other) playbooks for common tasks - Log aggregation (Logstash/Splunk) filters and tagging - Monitoring (Nagios) checks - Ops dashboards There's also things that *might* belong here but maybe not: - Chef/Puppet/Ansible/Salt OpenStack config management modules Today these are generally either wrapped up in products from various companies, or in each company's github repo. For those of you who are still around at the design summit and don't have plans for tomorrow, how about we meet on Friday morning at the large white couch in the meridian foyer at 9am? Let's see what we can sort out. Thanks! ___ 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
