Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project
On 06/09/2015 10:20 AM, James Page wrote: LGTM - although for any initial repository migration, I'd like to see Ubuntu (from bzr) and Debian (git.debian.org) branches separately for projects that have Vcs branches for Ubuntu so that we can manage that delta I keep going on about effectively; that would include: ceilometer cinder designate glance heat horizon ironic keystone neutron neutron-fwaas neutron-lbaas neutron-vpnaas nova openstack-trove sahara swift Apart from the VCS and Maintainer: field, what difference do we have in the below packages? neutron-fwaas neutron-lbaas neutron-vpnaas swift Cheers, Thomas __ 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] [Ceph] Is it necessary to flatten Copy-on-write cloning for RBD-backed disks?
Hi Kun, On 09 Jun 2015, at 05:34, Kun Feng fengku...@gmail.com wrote: Hi all, I'm using ceph as storage backend for Nova and Glance, and merged the rbd-ephemeral-clone patch into Nova. As VM disks are Copy-on-write clones of a image, I have some concerns about this: 1. Since hundreds of vm disks based on one base file, is there any performance problems that IOs are loaded on this one paticular base file? This may be an issue but as Clint mentioned you’ll get reads served from OSD memory anyway, so this should be expectable. 2. Is it possible that the data of base file is damaged or PG/OSD containing data of this base file out of service, resulting as all the VMs based on that base file malfunctioned? This assumption is correct, if the parents gets a corrupted block that hasn’t been written to the clone yet, your clone will get the corrupted block on a write request. If so, flattening Copy-on-write clones may do some help. Is it necessary to do it? People have expressed the concern, but no one has ever seen such thing happening (as far as I know), so it’s really up to you to flatten the clone. There is a patch that needs to be reworked that will allow to flatten all the clone after their creation in Nova. Hopefully this will get into Liberty. __ 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 Cheers. Sébastien Han Senior Cloud Architect Always give 100%. Unless you're giving blood. Mail: s...@redhat.com Address: 11 bis, rue Roquépine - 75008 Paris __ 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] [infra] how to trigger a set of jenkins jobs
Hi infra team, The origin concept of jenkins is one trigger one job. For example, the job neutron-unit-test-py27 could respond a new change set from neutron upstream. But the truth is that a gerrit event trigger a set of jenkins jobs: py27-unittest, pep8-check, and many dsvm jobs... How can I configure my jenkins like this? -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ 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] Mellanox CI Issues
On 5 June 2015 at 15:29, Moshe Levi mosh...@mellanox.com wrote: Hi Dan, I just want to update you that the report success after short less-than-a-minute run is Zuul problem see [1]. This is happened because we apply filter rules to run only on PCI code to reduce load on our CI System. I think the Xen Project CI is having similar issues due to using Zuul and skipping tests causing an empty positive vote. Unfortunately we missed this issue in our monitoring because all the job in the Jenkins were looking good and just Zuul reports also when no Jenkins job was scheduled. I talked also with John Garbutt and it seem that the recommendation is to filter only doc and test folders, but still I would like to filter some other folders like 1. nova/nova/virt/hyperv 2. nova/nova/virt/ironic 3. nova/nova/virt/vmwareapi 4. nova/nova/virt/xenapi Is there any Nova CI guidelines for file filtering? Not yet. Ideally we want you to run on every change, that gives us the most confidence in the tests. But skipping docs only stuff and unit test only stuff makes sense though, just like how we don't run tempest for those changes. Now that might not be possible due to hardware costs, or similar, at which point, we should talk about what things it might make sense to skip. Your above list makes quite a bit of sense I guess. Thanks, John Again I would like to apologize for the inconvenient. [1] https://review.openstack.org/#/c/188383/ Thank, Moshe Levi. -Original Message- From: Lenny Verkhovsky Sent: Monday, June 01, 2015 11:21 PM To: Dan Smith; OpenStack Development Mailing List (not for usage questions) Cc: Moshe Levi Subject: RE: [nova] Mellanox CI Issues Hi Dan, I disabled Mellanox Nova CI from commenting and will check this issue first thing tomorrow morning. Thanks and my deepest apologies. Lenny Verkhovsky -Original Message- From: Dan Smith [mailto:d...@danplanet.com] Sent: Monday, June 01, 2015 7:41 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Moshe Levi; Lenny Verkhovsky Subject: [nova] Mellanox CI Issues Hi, Mellanox CI has been broken for a while now. Test runs are reported as successful after an impossibly short less-than-a-minute run. Could the owners of this please take a look and address the problem? At least disabling commenting while working on the issue would be helpful. Also, on success, the bot doesn't post the log files, which is (a) inconsistent with other test bots and (b) not very helpful for validating that success is real. This is especially relevant right now, given that we know the success reports are erroneous at the moment. This is the second time (in recent memory) that Mellanox CI has gone off the rails for a decent amount of time without being noticed by the owners. If this continues, I'll be in favor of removing commenting privileges for this account and will be hesitant to throw in my support for re-enabling it. Running CI against gerrit comes with serious responsibility for monitoring! Thanks! --Dan __ 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] [packaging] Adding packaging as an OpenStack project
Hi Derek, 2015-06-09 0:34 GMT+02:00 Derek Higgins der...@redhat.com: This patch would result in 80 packaging repositories being pulled into gerrit. I personally would prefer to start with fewer but common packages between all RPM distros (is there more than Red Hat and SUSE ?) than starting the process with 80, but I wouldn't object to that. o exactly what namespace/prefix to use in the naming, I've seen lots of opinions but I'm not clear if we have come to a decision o Should we use rdo in the packaging repo names and not rpm? I think this ultimatly depends whether the packaging can be shared between RDO and Suse or not. Well, we're (SUSE that is) are interested in sharing the packaging, and a non-RDO prefix would be preferred for the upstream coordination efforts. It is all a bit fuzzy for me right now as I'm not entirely sure our goals for packaging are necessarily the same (e.g. we have the tendency to include patches that have not been merged but are proposed upstream and are +1'ed already into our packages should there be a pressing need for us to do so (e.g. fixes an important platform bug), but maybe we can find enough common goals to make this a benificial effort for all of us. There are quite some details to sort out as our packaging is for historical and for various policy reasons that we need to stick to slightly different than the RDO packaging. I think going over those and see how we can merge them in a consolidated effort (or maintain two variants together) is the first step IMHO. Another important point for us is that we start with equal rights on the upstream collaboration (at least on the RPM side, I am fine with decoupling and not caring about the deb parts). I'm not overly optimistic that a single PTL would be able to cover both the DEB and RPM worlds, as I perceive them quite different in details. Greetings, Dirk __ 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] Mellanox CI Issues
-Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] On 5 June 2015 at 15:29, Moshe Levi mosh...@mellanox.com wrote: I talked also with John Garbutt and it seem that the recommendation is to filter only doc and test folders, but still I would like to filter some other folders like 1. nova/nova/virt/hyperv 2. nova/nova/virt/ironic 3. nova/nova/virt/vmwareapi 4. nova/nova/virt/xenapi Not yet. Ideally we want you to run on every change, that gives us the most confidence in the tests. The XenProject CI currently skips drivers which we can't see how they can affect the tests as well - including changes in other drivers. What are the cases why the XenProject CI should vote on a vmwareapi change? Your above list makes quite a bit of sense I guess. I hope that there is no need to run the tests when the code change is in another driver, as suggested above. Can you confirm that you're happy with them not being run? For reference, we currently have the following skip-if defined in our layout.conf: all-files-match-any: - ^.*\.rst$ - ^doc/.*$ - ^nova/tests/.*$ - ^nova/virt/baremetal/.*$ - ^nova/virt/hyperv/.*$ - ^nova/virt/ironic/.*$ - ^nova/virt/vmwareapi/.*$ - ^nova/virt/xenapi/.*$ - ^tools/.*$ - ^tox.ini$ Thanks, Bob __ 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] [packaging] Adding packaging as an OpenStack project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/06/15 22:36, Thomas Goirand wrote: [...] I have sorted this list into categories, and sorted these categories in an increasing order of likelihood to be maintained in upstream gerrit. On the below list, I believe we should have in upstream gerrit, at least: - OpenStack maintained libraries and clients - Debian specific packages (because that's needed tools for building and running a Debian package based CI) - server packages All the 3rd party Python modules could either stay within the PKG OpenStack Debian team, or move to the DPMT (Debian Python Module Team). Though I will *refuse* that these packages are switched from Git to SVN, so we will have to wait until the DPMT finishes the switch. I've heard that Tumbleweed (that's a nick name...) is close to have this migration finished though. I understand the migration to be nearing completion as well, which unblocks any team repository migration activity. Also, probably it would make sense to keep some of the tooling within the PKG OpenStack group. I'm thinking about all the unit test stuff, like testr, subunit, and all of its dependencies (testtools, testscenarios, etc.). Maybe it's a good fit for upstream packaging too? Please voice your opinion here. I'd be tempted to leave then in Debian under the DPMT - they don't release on the same cadence as OpenStack afaik - so it may be easier to just collaborate in-distro on that stuff. Suggestion - leave them out of the migration for now - we can always include them later if the requirement/need arises. I would then like to keep side packages and Key dependencies within the PKG OpenStack group in alioth.debian.org. side packages - +1 fine with me key dependencies - see below. This overall means that we'd push 107 repositories to Gerrit, and even 119 if we include TripleO. And of course, this list would grow over time (because that's OpenStack you know... things always grow, and never shrink...). It took me some time to produce this list below. I hope that's useful. It is - thank-you for doing this work. Key dependencies (4): - alembic migrate I'd put these two as candidates for migration to the DPMT. novnc rabbitmq-server OK - these two are fine where they are. 3rd party Python modules (101): --- [...] testresources websockify LGTM TripleO (12): - python-dib-utils python-diskimage-builder python-os-apply-config python-os-client-config python-os-cloud-config python-os-collect-config python-os-net-config python-os-refresh-config tripleo-heat-templates tripleo-image-elements tuskar tuskar-ui server packages (25): - barbican ceilometer cinder designate glance heat heat-cfntools horizon ironic keystone murano murano-agent murano-dashboard networking-arista networking-mlnx neutron neutron-fwaas neutron-lbaas neutron-vpnaas nova openstack-trove rally sahara swift swift-plugin-s3 LGTM - although for any initial repository migration, I'd like to see Ubuntu (from bzr) and Debian (git.debian.org) branches separately for projects that have Vcs branches for Ubuntu so that we can manage that delta I keep going on about effectively; that would include: ceilometer cinder designate glance heat horizon ironic keystone neutron neutron-fwaas neutron-lbaas neutron-vpnaas nova openstack-trove sahara swift Debian specific packages (3): - openstack-debian-images openstack-meta-packages openstack-pkg-tools OpenStack maintained libraries and clients (79): openstack-doc-tools openstack-nose oslo-config oslo-sphinx oslo.messaging oslo.rootwrap python-barbicanclient python-bashate python-ceilometerclient python-cinderclient python-congressclient python-debtcollector python-designateclient python-django-openstack-auth python-glance-store python-glanceclient python-hacking python-heatclient python-hp3parclient python-hplefthandclient python-ironicclient python-keystoneclient python-keystonemiddleware python-mistralclient python-muranoclient python-neutronclient python-novaclient python-openstackclient python-oslo-context python-oslo.concurrency python-oslo.db python-oslo.i18n python-oslo.log python-oslo.middleware python-oslo.policy python-oslo.serialization python-oslo.utils python-oslo.versionedobjects python-oslo.vmware python-oslotest python-osprofiler python-pbr python-proliantutils python-pycadf python-pyeclib python-saharaclient python-savannaclient python-swiftclient python-taskflow python-tempest-lib python-tooz python-troveclient python-tuskarclient python-xstatic python-xstatic-angular python-xstatic-angular-bootstrap python-xstatic-angular-cookies python-xstatic-angular-lrdragndrop python-xstatic-angular-mock python-xstatic-bootstrap-datepicker python-xstatic-bootstrap-scss python-xstatic-d3
Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC
+1 On 08/06/15 18:37, Smigiel, Dariusz wrote: Folks, Several people have messaged me from EMEA timezones that 1600UTC fits right into the middle of their family life (ferrying kids from school and what-not) and 1700UTC while not perfect, would be a better fit time-wise. For all people that intend to attend the 1600 UTC, could I get your feedback on this thread if a change of the 1600UTC timeslot to 1700UTC would be acceptable? If it wouldn't be acceptable, please chime in as well. Thanks -steve +1 It suits me. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [stable] No longer doing stable point releases
On 06/08/2015 12:46 AM, Alan Pevec wrote: How do you check if project X in version n works with project Y in version m, using this non-scheduled point release free for all model? That was an illusion of point releases, as Thierry said there wasn't significantly more testing and I don't remember any testing reports during stable freeze periods. There is: the point releases end up in all distributions, and we all do our own tests. All we had was upstream CI testing, but that's what we get for every commit. The stable release gate is famously always broken, and now that we're proposing to stop doing the point releases, it's going to be even worse. Why every 2 weeks? Why every month? Sure, no problem, every distro can update whenever it works for them, what is important for me is that we have a common reference points. With plan D that would be automatically generated maj.min.N where N is the number of commits since maj.min tag which doesn't depend on anyone's manually pushing git tag. As long as we have a common reference point, manually or not, I'm satisfied. Not synchronizing brings a bunch of problems. The only problem raised by synchronous point releases is we don't have enough resources, which I fail to understand, given how cheap it is to tag a release. If the release managers don't have enough time to do so, it is my view that it's ok to give this power to individual projects. But that's orthogonal to having synchronous point releases. Tag is indeed cheap, this is more about reflecting reality and not keeping this synchronized illusion alive. If distros are releasing packages based on the same tag, I fail to see where we have an illusion. BTW point release process is more[1] than just pushing signed git tag, the most time consuming work is cats herding (i.e. pushing for reviews before the freeze) and Launchpad pruning. The former was hopeless and will be even more with big-tent and the latter we should avoid by automatically generated changelog. So, if I get you right, you are saying that our QA work isn't working as well as we want, and therefore, we should accept that fact, and get rid of that QA work. While it's important to realize what our problems are, I don't think this is going to the right direction still... :( Cheers, Thomas Goirand (zigo) __ 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] [all] [stable] No longer doing stable point releases
On 06/07/2015 06:13 PM, Ian Cordasco wrote: If you consider *every* commit to be a release, then your life becomes easier. What does this mean? Am I supposed to upload a patched release to Debian every day? I suppose I didn't understand you correctly here. This discussion is about stable branches. Maybe early in a stable branch's life there are lots of commits, but as it grows older, the number of commits made to a stable branch certainly isn't 1 per day. If you consider all the projects within the big-tent, that's a lot of commits still. If we were to do this in downstream distros, we wouldn't have an upstream number matching each commit. This would be a problem because we would loose track of what version we're at between distros. It seems from other discussions that there is little coordination between distros in the first place, and that is only beginning to improve now, but only between close relatives (Ubuntu Debian, RHEL CentOS Fedora, etc.). If that's the case, the work to improve coordination, including sharing repositories, etc. would seem to alleviate this concern regardless of coordinated release tagging. That's far from being in place. Also, while we are removing point releases, and support for Icehouse, we still don't have a common private Gerrit for security, which we've been told about 2 years ago. Removing collaboration tools before new ones are in place is definitively not the way to go. That said, I know you've said in the past that you do most of your packaging in your free-time because it's not part of your job responsibilities. I'm a full time Mirantis employee, and it's my full-time job to do packaging of OpenStack in Debian (that, plus helping to do MOS). I know the same is true for a bunch of OpenStack's packagers (including the Gentoo packager). I believe Gentoo is the only case. As someone who spends the majority of their free time supporting other software beyond OpenStack, I understand how insulting it is to be told you have to do more work in the time that you're volunteering. It being a paid-for job IMO doesn't change the fact we should work efficiently and the correct way. :) I've only been around for a little less than a year though, so I have no memory of a backport in one service breaking another. It happened that requirements changed from one version to the next, and 2 projects needed to be updated at once. I don't see this happening smoothly if we don't have coordinated point releases. And yes, I know, requirements are *supposed* to be frozen, but between the theory and what really happens, there's a world... Cheers, Thomas Goirand (zigo) __ 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] [all] [stable] No longer doing stable point releases
On 06/01/2015 01:20 PM, Dimitri John Ledkov wrote: On 29 May 2015 at 14:41, Thierry Carrez thie...@openstack.org wrote: Hi everyone, TL;DR: - We propose to stop tagging coordinated point releases (like 2015.1.1) - We continue maintaining stable branches as a trusted source of stable updates for all projects though Ideally I would still want to see tarballs published, even if they are generated with a $ git describe --tags name in it. E.g. keystone-2015.1.0-3-g1373bfa.tar.gz Please, no dashes in version numbers. While Debian *can* cope with them, it's recommended to avoid it (as the dash is the separator between the upstream version and the Debian release number). Cheers, Thomas Goirand (zigo) __ 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] [all] [stable] No longer doing stable point releases
On 06/08/2015 12:25 AM, Alan Pevec wrote: and *Plan D* would be to start doing automatic per-project micro-versions on each commit: e.g. 2015.1.N where N is increased on each commit. How do you gpg sign these tags? I hope the solution isn't to store a key in infra without a passphrase. Plan D doesn't include git tags, 2015.1.N would be generated by PBR automatically. Then please don't do Plan D. I don't use tarballs, and I don't have the intention to use them. It's not an efficient way for me to work. Cheers, Thomas Goirand (zigo) __ 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] [all] [stable] No longer doing stable point releases
On 06/07/2015 05:57 PM, Ian Cordasco wrote: On 6/7/15, 03:41, Thomas Goirand z...@debian.org wrote: On 05/29/2015 09:23 PM, Ian Cordasco wrote: Could you explain this as well? Do you mean fragmentation between what distros are offering? In other words, Ubuntu is packaging Kilo @ SHA1 and RHEL is at SHA2. I'm not entirely certain that's a bad thing. That seems to give the packagers more freedom. What happens when there's a security patch? Will upstream publish patches for each and every distro? I don't believe so. Does upstream do that now? I don't think so. The point it: they don't need to do it, because all distro are using the same reference point (ie: the point releases). On 05/29/2015 09:23 PM, Ian Cordasco wrote: The point of the embargo is to give time for testing patches and prepare a new patched version. Sometimes, we discover problems with the provided patch during the embargo period. Yes, we use the embargo to sometimes adapt the patch to the version we have in our distributions, but we would prefer if that work wasn't needed. But there aren't point releases for every CVE fix. There are point releases that are coordinated at the moment. So if you're waiting for those point releases to publish a new version of that package in your package repositories, that's news to me. I've seen packagers take patches and apply them and merely change the build metadata. Is this only done for severe CVEs at the moment? I try to do a security fix on every OSSA the way you describe above. I suppose other distros are doing the same (but I didn't take the time to check). If every commit were a release, then you could all synchronize on that, if you all packaged each commit or at least, generate a new package each time a CVE is publicly patched through gerrit. Adding a bunch of unrelated commits for a CVE fix may be acceptable for Debian Sid, but it wouldn't for the stable distribution. But anyway, the discussion about point releases is only barely related to CVE fixing. The point is that we would like to have a common reference point between distribution, were we would all be able to say: version X.Y.Z of this server has a bug, it broke the CI of N and M distribution, we need a fix release. Without such a coordination, we wouldn't have as much attention from upstream to produce clean point releases. Cheers, Thomas Goirand (zigo) __ 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] [Murano] python-openstackclient support
Hi Kirill, It's definitely a great idea, it needs to be verified though AFAIK all openstack projects are moving to support python-openstackclient. I think we should file a blueprint around that and start looking at that on background. I think it will be not a big deal to support python-openstackclient. On Thu, Apr 23, 2015 at 3:04 AM, Stan Lagun sla...@mirantis.com wrote: +1 for the idea though not sure on priority of this since we have so many way more important things to implement in Kilo. I'd say that would be a great contribution if we find someone willing to contribute it :) Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Thu, Apr 23, 2015 at 1:55 AM, Kirill Zaitsev kzait...@mirantis.com wrote: Since python-openstackclient is now a part of openstack — I guess it would be a good idea to support it in murano. It has setuptools-based plugin system, and it should be fairly easy to add murano commands as plugins to it. BTW, It’s based on cliff and has a terrific completion support (which is basically why I started looking into the issue in the first place =)) What do you think, is it a good idea? -- Kirill Zaitsev Sent with Airmail __ 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 -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ 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] The Nova API in Kilo and Beyond
On 08/06/15 18:22, Jay Pipes wrote: On 06/05/2015 10:56 AM, Neil Jerram wrote: I guess that's why the GNU autoconf/configure system has always advised testing for particular wanted features, instead of looking at versions and then relying on carnal knowledge to know what those versions imply. I'm pretty sure you meant tribal knowledge, not carnal knowledge :) -jay http://en.wikipedia.org/wiki/Carnal_knowledge Gosh, that article needs a restricted rating. :-) You're right that I didn't mean it in that sense! However, I _think_ the phrase is fairly commonly used, at least in the UK, also to mean something more like tribal or insider knowledge. I hope so, anyway. :-) Regards, Neil __ 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] [all] [stable] No longer doing stable point releases
On 06/08/2015 05:42 PM, Jeremy Stanley wrote: On 2015-06-07 10:55:29 +0200 (+0200), Thomas Goirand wrote: How do you gpg sign these tags? I hope the solution isn't to store a key in infra without a passphrase. How does, e.g., Debian sign its Release file for jessie-proposed-updates? I hope the solution isn't to store the ftp-master automatic archive signing key in infra without a passphrase. (This is a rhetorical question... I see from comments at https://wiki.debian.org/SecureApt that it is indeed the case.) In fact, I don't really mind this. It's at least an attestation that the machine where the signature was generated had access to the automatic signing key, which is in turn signed by and revocable by the systems administrators entrusted to protect that machine. Fair enough. And I'll trust you will safeguard everything correctly. :) Thomas __ 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] [all] [stable] No longer doing stable point releases
On 06/08/2015 06:10 PM, Jeremy Stanley wrote: On 2015-06-08 16:53:21 +0100 (+0100), Dave Walker wrote: This breaks the desire of wanting to have a shared version scheme if consumers add their own local patches via git. This works fine for consumers that do not use git for handling their local patches, but does not support the model of allowing the user to rebase using git. Perhaps tags ARE superior for this? Agreed, even the .devN (or earlier .postN) versioning has the same issue. If you rely on PBR autoversioning for non-tagged commits then your local commits _will_ conflict with upstream autoversions. The problem is that we use the 2 first numbers as major version. If instead of: 2015.1.N we switch to something like: 20151.X.Y then we restore sanity and a real semver system. Cheers, Thomas Goirand (zigo) __ 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-operators] [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries in addn_hosts causing no IP allocation
Just to be sure, I assume we're focussing here on the issue that Daniel
reported
Yes.
To be clear, though, what code are you trying to reproduce on? Current
master?
I was trying on 2014.1.3, which is the version I understand to be on Fuel
5.1.1.
I'm not clear whether that would qualify as 'concurrent', in the sense
that you have in mind.
It doesn't look like it based on the pseudocode. I was thinking of a
condition where a port is deleted nearly very quickly after it was created.
Is that possible with your test? If not, then my theory about out-of-order
notifications might not be any good.
On Tue, Jun 9, 2015 at 3:34 AM, Neil Jerram neil.jer...@metaswitch.com
wrote:
On 09/06/15 01:15, Kevin Benton wrote:
I'm having difficulty reproducing the issue. The bug that Neil
referenced (https://bugs.launchpad.net/neutron/+bug/1192381) looks like
it was in Icehouse well before the 2014.1.3 release that looks like Fuel
5.1.1 is using.
Just to be sure, I assume we're focussing here on the issue that Daniel
reported (IP appears twice in Dnsmasq config), and for which I described a
possible corollary (Dnsmasq config size keeps growing), and NOT on the
Another DHCP agent problem that I mentioned below. :-)
BTW, now that I've reviewed the history of when my team saw this, I can
say that it was actually first reported to us with the 'IP appears twice in
Dnsmasq config' symptom - i.e. exactly the same as Daniel's case. The fact
of the Dnsmasq config increasing in size was noticed later.
I tried setting the agent report interval to something higher than the
downtime to make it seem like the agent is failing sporadically to the
server, but it's not impacting the notifications.
Makes sense - that's the effect of the fix for 1192381.
To be clear, though, what code are you trying to reproduce on? Current
master?
Neil, does your testing where you saw something similar have a lot of
concurrent creation/deletion?
It was a test of continuously deleting and creating VMs, with this
pseudocode:
thread_pool = new_thread_pool(size=30)
for x in range(0,30):
thread_pool.submit(create_vm)
thread_pool.wait_for_all_threads_to_complete()
while True:
time.sleep(5)
for x in range(0,int(random.random()*5)):
thread_pool.submit(randomly_delete_a_vm_and_create_a_new_one)
I'm not clear whether that would qualify as 'concurrent', in the sense
that you have in mind.
Regards,
Neil
On Mon, Jun 8, 2015 at 12:21 PM, Andrew Woodward awoodw...@mirantis.com
mailto:awoodw...@mirantis.com wrote:
Daniel,
This sounds familiar, see if this matches [1]. IIRC, there was
another issue like this that was might already address this in the
updates into Fuel 5.1.2 packages repo [2]. You can either update the
neutron packages from [2] Or try one of community builds for 5.1.2
[3]. If this doesn't resolve the issue, open a bug against MOS dev
[4].
[1] https://bugs.launchpad.net/bugs/1295715
[2] http://fuel-repository.mirantis.com/fwm/5.1.2/ubuntu/pool/main/
[3] https://ci.fuel-infra.org/
[4] https://bugs.launchpad.net/mos/+filebug
On Mon, Jun 8, 2015 at 10:15 AM Neil Jerram
neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com
wrote:
Two further thoughts on this:
1. Another DHCP agent problem that my team noticed is that it
call_driver('reload_allocations') takes a bit of time (to
regenerate the
Dnsmasq config files, and to spawn a shell that sends a HUP
signal) -
enough so that if there is a fast steady rate of port-create and
port-delete notifications coming from the Neutron server, these
can
build up in DHCPAgent's RPC queue, and then they still only get
dispatched one at a time. So the queue and the time delay
become longer
and longer.
I have a fix pending for this, which uses an extra thread to
read those
notifications off the RPC queue onto an internal queue, and then
batches
the call_driver('reload_allocations') processing when there is a
contiguous sequence of such notifications - i.e. only does the
config
regeneration and HUP once, instead of lots of times.
I don't think this is directly related to what you are seeing -
but
perhaps there actually is some link that I am missing.
2. There is an interesting and vaguely similar thread currently
being
discussed about the L3 agent (subject L3 agent rescheduling
issue) -
about possible RPC/threading issues between the agent and the
Neutron
server. You might like to review that thread and see if it
describes
any problems analogous to your DHCP one.
Regards,
Neil
On 08/06/15 17:53, Neil Jerram wrote:
My team has seen a
Re: [openstack-dev] Tracking bugs in apps on launchpad
+1 Can’t find any objectsions to separating murano-apps from murano. -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 8 Jun 2015 at 17:13:22, Dmitro Dovbii (ddov...@mirantis.com) wrote: Hi, Serg! Nice! Why only bug tracking? I'm looking forward to the first blueprint submitting :) Regards, Dmytro Dovbii 2015-06-08 16:34 GMT+03:00 Serg Melikyan smelik...@mirantis.com: We originally created https://launchpad.net/murano-applications, and I misspelled address in my first e-mail, but after I was pointed out to the mistake I've decided to create new project with URL https://launchpad.net/murano-apps that correspond to the repository name. On Mon, Jun 8, 2015 at 4:01 PM, Serg Melikyan smelik...@mirantis.com wrote: Hi folks, We used to track bugs that we have in applications published in openstack/murano-apps repository directly on launchpad.net/murano but sometimes it's really inconvenient: * applications are not a part of the murano * it's hard to properly prioritize bugs, because critical bug for app is not critical at all for murano We had created murano-apps project on launchpad sometimes ago, but never truly used this project. I propose to move existing bugs for applications to https://launchpad.net/murano-apps and use this project as place for tracking bugs in openstack/murano-apps repository. Folks, what do you think about that? -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ 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] [Openstack-operators] [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries in addn_hosts causing no IP allocation
On 09/06/15 01:15, Kevin Benton wrote:
I'm having difficulty reproducing the issue. The bug that Neil
referenced (https://bugs.launchpad.net/neutron/+bug/1192381) looks like
it was in Icehouse well before the 2014.1.3 release that looks like Fuel
5.1.1 is using.
Just to be sure, I assume we're focussing here on the issue that Daniel
reported (IP appears twice in Dnsmasq config), and for which I described
a possible corollary (Dnsmasq config size keeps growing), and NOT on the
Another DHCP agent problem that I mentioned below. :-)
BTW, now that I've reviewed the history of when my team saw this, I can
say that it was actually first reported to us with the 'IP appears twice
in Dnsmasq config' symptom - i.e. exactly the same as Daniel's case.
The fact of the Dnsmasq config increasing in size was noticed later.
I tried setting the agent report interval to something higher than the
downtime to make it seem like the agent is failing sporadically to the
server, but it's not impacting the notifications.
Makes sense - that's the effect of the fix for 1192381.
To be clear, though, what code are you trying to reproduce on? Current
master?
Neil, does your testing where you saw something similar have a lot of
concurrent creation/deletion?
It was a test of continuously deleting and creating VMs, with this
pseudocode:
thread_pool = new_thread_pool(size=30)
for x in range(0,30):
thread_pool.submit(create_vm)
thread_pool.wait_for_all_threads_to_complete()
while True:
time.sleep(5)
for x in range(0,int(random.random()*5)):
thread_pool.submit(randomly_delete_a_vm_and_create_a_new_one)
I'm not clear whether that would qualify as 'concurrent', in the sense
that you have in mind.
Regards,
Neil
On Mon, Jun 8, 2015 at 12:21 PM, Andrew Woodward awoodw...@mirantis.com
mailto:awoodw...@mirantis.com wrote:
Daniel,
This sounds familiar, see if this matches [1]. IIRC, there was
another issue like this that was might already address this in the
updates into Fuel 5.1.2 packages repo [2]. You can either update the
neutron packages from [2] Or try one of community builds for 5.1.2
[3]. If this doesn't resolve the issue, open a bug against MOS dev [4].
[1] https://bugs.launchpad.net/bugs/1295715
[2] http://fuel-repository.mirantis.com/fwm/5.1.2/ubuntu/pool/main/
[3] https://ci.fuel-infra.org/
[4] https://bugs.launchpad.net/mos/+filebug
On Mon, Jun 8, 2015 at 10:15 AM Neil Jerram
neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote:
Two further thoughts on this:
1. Another DHCP agent problem that my team noticed is that it
call_driver('reload_allocations') takes a bit of time (to
regenerate the
Dnsmasq config files, and to spawn a shell that sends a HUP
signal) -
enough so that if there is a fast steady rate of port-create and
port-delete notifications coming from the Neutron server, these can
build up in DHCPAgent's RPC queue, and then they still only get
dispatched one at a time. So the queue and the time delay
become longer
and longer.
I have a fix pending for this, which uses an extra thread to
read those
notifications off the RPC queue onto an internal queue, and then
batches
the call_driver('reload_allocations') processing when there is a
contiguous sequence of such notifications - i.e. only does the
config
regeneration and HUP once, instead of lots of times.
I don't think this is directly related to what you are seeing - but
perhaps there actually is some link that I am missing.
2. There is an interesting and vaguely similar thread currently
being
discussed about the L3 agent (subject L3 agent rescheduling
issue) -
about possible RPC/threading issues between the agent and the
Neutron
server. You might like to review that thread and see if it
describes
any problems analogous to your DHCP one.
Regards,
Neil
On 08/06/15 17:53, Neil Jerram wrote:
My team has seen a problem that could be related: in a churn
test where
VMs are created and terminated at a constant rate - but so
that the
number of active VMs should remain roughly constant - the
size of the
host and addn_hosts files keeps increasing.
In other words, it appears that the config for VMs that have
actually
been terminated is not being removed from the config file.
Clearly, if
you have a limited pool of IP addresses, this can eventually
lead to the
problem that you have described.
For your case - i.e. with Icehouse - the problem might be
https://bugs.launchpad.net/neutron/+bug/1192381. I'm not
Re: [openstack-dev] [Murano] python-openstackclient support
https://blueprints.launchpad.net/python-muranoclient/+spec/openstack-client-plugin-support I’ve done that a while ago, already =). Could you please approve it? -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 9 Jun 2015 at 11:45:56, Serg Melikyan (smelik...@mirantis.com) wrote: Hi Kirill, It's definitely a great idea, it needs to be verified though AFAIK all openstack projects are moving to support python-openstackclient. I think we should file a blueprint around that and start looking at that on background. I think it will be not a big deal to support python-openstackclient. On Thu, Apr 23, 2015 at 3:04 AM, Stan Lagun sla...@mirantis.com wrote: +1 for the idea though not sure on priority of this since we have so many way more important things to implement in Kilo. I'd say that would be a great contribution if we find someone willing to contribute it :) Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Thu, Apr 23, 2015 at 1:55 AM, Kirill Zaitsev kzait...@mirantis.com wrote: Since python-openstackclient is now a part of openstack — I guess it would be a good idea to support it in murano. It has setuptools-based plugin system, and it should be fairly easy to add murano commands as plugins to it. BTW, It’s based on cliff and has a terrific completion support (which is basically why I started looking into the issue in the first place =)) What do you think, is it a good idea? -- Kirill Zaitsev Sent with Airmail __ 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 -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ 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] [Murano] python-openstackclient support
Hi all! I support the idea! Kirill, how much time do you think blueprint implementation will take? On Tue, Jun 9, 2015 at 2:46 PM, Kirill Zaitsev kzait...@mirantis.com wrote: https://blueprints.launchpad.net/python-muranoclient/+spec/openstack-client-plugin-support I’ve done that a while ago, already =). Could you please approve it? -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 9 Jun 2015 at 11:45:56, Serg Melikyan (smelik...@mirantis.com) wrote: Hi Kirill, It's definitely a great idea, it needs to be verified though AFAIK all openstack projects are moving to support python-openstackclient. I think we should file a blueprint around that and start looking at that on background. I think it will be not a big deal to support python-openstackclient. On Thu, Apr 23, 2015 at 3:04 AM, Stan Lagun sla...@mirantis.com wrote: +1 for the idea though not sure on priority of this since we have so many way more important things to implement in Kilo. I'd say that would be a great contribution if we find someone willing to contribute it :) Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Thu, Apr 23, 2015 at 1:55 AM, Kirill Zaitsev kzait...@mirantis.com wrote: Since python-openstackclient is now a part of openstack — I guess it would be a good idea to support it in murano. It has setuptools-based plugin system, and it should be fairly easy to add murano commands as plugins to it. BTW, It’s based on cliff and has a terrific completion support (which is basically why I started looking into the issue in the first place =)) What do you think, is it a good idea? -- Kirill Zaitsev Sent with Airmail __ 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 -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ 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] [Oslo][Automaton] Proposal for new core reviewer (min pae)
Thanks Davanum :) On Mon, Jun 8, 2015 at 12:00 PM, Davanum Srinivas dava...@gmail.com wrote: +1 from me Josh. welcome Min Pae. -- dims On Mon, Jun 8, 2015 at 2:31 PM, Joshua Harlow harlo...@outlook.com wrote: Greetings all stackers, I propose that we add Min Pae (sputnik13) to the automaton-core team. Min has been actively contributing to taskflow for a while now and as automaton (the library came out of taskflow) is a new library it would be great to have his participation there as well. He is willing (and able!) to help with the review load when he can. He has provided quality reviews in other projects and would be a welcome addition in helping make automaton the best library it can be! Overall I think he would make a great addition to the core review team. Please respond with +1/-1. Thanks much! -- Joshua Harlow It's openstack, relax... | harlo...@yahoo-inc.com __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [Fuel][Oslo][RabbitMQ][Shovel] Deprecate mirrored queues from HA AMQP cluster scenario
Nodes can become unavailable with Shovel or Federation as well. While both plugins will enqueue undelivered/unconfirmed messages internally, recovery can take a while or never happen. So replication is certainly necessary. RabbitMQ has a guide that mentions several possible failure scenarios: http://www.rabbitmq.com/reliability.html Note that a lot of them do not even involve a messaging server, and would be just as relevant for Pacemaker setups. This is as much an oslo.messaging design concern as whatever messaging technology is used. There's ongoing work on publisher confirms — one of the things oslo.messaging must have — and heartbeats, for faster peer unavailability detection. Shovel or Federation or AP-style mirroring wouldn't change this. So please clarify what problems are being tackled here. Currently there are several largely unrelated things mentioned: rabbitmqctl timeouts, Fuel provisioning, Mnesia being very consistency-oriented, desired oslo.messaging fault tolerance improvements. I'm not sure how some of these relate to each other and why OpenStack has to work around issues that should be reported to the RabbitMQ team. I will push for introducing the most basic timeout support in ctl in the next bug fix release. On Mon, Jun 8, 2015 at 5:24 PM, Bogdan Dobrelya bdobre...@mirantis.com wrote: RabbitMQ team member here. Thank you for a quick response, Michael! Neither Shovel nor Federation will replace mirroring. Shovel moves messages from a queue to an exchange (within a single node or between remote nodes and/or clusters). It doesn't replicate anything. Yes, the idea was to not just replace, but redesign OpenStack libs to use cluster-less messaging as well. It should assume that some messages from RPC conversations may be lost. And that messages aren't synced between different AMQP nodes specified in the config of OpenStack services (rabbit_hosts=). Federation has two parts to it: * Queue federation: no replicate, distributes messages from a single logical queue between N nodes or clusters, when there are no local consumers to consume them. * Exchange federation replicates a stream of messages going through an exchange. As messages are consumed upstream, downstream has no way of knowing about it. The right thing to do here is introduce timeouts to rabbitmqctl, which was 99% finished in the past but some RabbitMQ team members felt it should produce more detailed error messages, which extended the scope of the change significantly. While Mnesia indeed needs to be replaced to introduce AP (as in CAP) style mirroring, the issue you're bringing up here has nothing to do with Mnesia. Mnesia is not used by rabbitmqctl, and it is not used to store messages. It's a rabbitmqctl issue, and potentially a hint that you may want to reduce net_ticktime value (say, to 5-10 seconds) to make queue master unavailability detected faster. Thank you, I updated the bug comments [0]. We will test this option as well. [0] https://bugs.launchpad.net/fuel/+bug/1460762/comments/23 1. http://www.rabbitmq.com/nettick.html -- MK Staff Software Engineer, Pivotal/RabbitMQ -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando __ 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 -- MK Staff Software Engineer, Pivotal/RabbitMQ __ 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] [glance] [nova] Glance bug with Kilo upgrade Nova
On 09/06/15 09:22 +0200, Flavio Percoco wrote: On 09/06/15 07:09 +, Bhandaru, Malini K wrote: Flavio, would a DB script that writes an empty string or NOP or something instead of NULL In the column do the trick? Then the problem degenerates to a new DB upgrade script. I now remembered about a change[0] - that I wrote myself - that required a bump on the API version - which we did - that allows None values to be returned in the API. This is probably what is causing this behavior. A DB migration would certainly work, I'd love to avoid it but I guess that's the best solution in this case. Actually, we can't just migrate the database as there might be custom properties that were explicitly set to None. I'll keep you posted Cheers, Flavio [0] https://review.openstack.org/#/c/138184/ Regards Malini -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Monday, June 08, 2015 11:47 PM To: OpenStack Development Mailing List (not for usage questions) Cc: openstack-operat...@lists.openstack.org Subject: Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova On 08/06/15 11:46 -0400, Clayton O'Neill wrote: We tested testing Kilo upgrades in our hardware dev environments last week and the second time through ran into this bug which right now is probably a show-stopper for us. https://bugs.launchpad.net/glance/+bug/1419823 The issue here is that the v1 Glance API allows you to create images with properties that are 'NULL' in the Glance database. For example: glance image-create --name cirros_test --disk-format qcow2 --container-format bare --file cirros-0.3.4-x86_64-disk.img --is-public True --is-protected True --progress --property description= It's apparently also fairly easy to end up with a NULL description when editing images properties via Horizon. The issue is that the v2 Glance API returns these NULL properties to the client, which then validates them against the schema returned by the v2 API. This schema returns specifies that the description property *must* be a string. In the Kilo release, Nova has been changed to use the v2 API, so suddenly this matters. The net effect is that end users can pretty easily create properties with NULL values, and then won't be able to boot instances using those images. What makes this worse is that it's completely opaque to end users, since this just reports that no node was available to schedule the instance. However, Nova *only* uses the v2 api to list images if the glance.allowed_direct_url_schemes config key is set in the config file. However, this config item defaults to an empty array, meaning that by default it's *always* set. There doesn't appear to be a way to unset a value with oslo-config that has a default value, blocking off that route to work around the issue. Disabling the v2 Glance API we don't think will work, since Nova appears to assume the v2 API is available. AFAIK, Nova supports V2 image-lists since before Juno when the allowed_direct_url_schemes config option is set. Are you referring to another change? Has the default been changed in Nova? I'm asking because I was working on this migration to V2 and we decided to postpone it to L. Another work around we've looked at is to change the DB schema for image properties (yuck) to not allow NULL values. This results in Glance returning a 500 error since glance-api is attempting to insert an invalid value. This is better than instances failing in an opaque fashion, but still pretty horrible. Has anyone else run into this issue yet? Are there other work arounds that we've not thought of other than Don't create images with NULL properties? User education is definitely an option, but given the failure mode, it's not a great solution for us. I believe this needs to be fixed in the client rather than the API and/or the schemas. I'll take a look at this right away. Another workaround could be updateting `schema-image.json` to add the schemas that are missing and let the client download the final schema from the V2 API. Keep an eye on the bug, patches coming your way (assuming what I have in mind will work). Flavio -- @flaper87 Flavio Percoco -- @flaper87 Flavio Percoco __ 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 -- @flaper87 Flavio Percoco pgpTl2fXkFZOj.pgp Description: 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
Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova
On 08/06/15 11:46 -0400, Clayton O'Neill wrote: We tested testing Kilo upgrades in our hardware dev environments last week and the second time through ran into this bug which right now is probably a show-stopper for us. https://bugs.launchpad.net/glance/+bug/1419823 The issue here is that the v1 Glance API allows you to create images with properties that are 'NULL' in the Glance database. For example: glance image-create --name cirros_test --disk-format qcow2 --container-format bare --file cirros-0.3.4-x86_64-disk.img --is-public True --is-protected True --progress --property description= It's apparently also fairly easy to end up with a NULL description when editing images properties via Horizon. The issue is that the v2 Glance API returns these NULL properties to the client, which then validates them against the schema returned by the v2 API. This schema returns specifies that the description property *must* be a string. In the Kilo release, Nova has been changed to use the v2 API, so suddenly this matters. The net effect is that end users can pretty easily create properties with NULL values, and then won't be able to boot instances using those images. What makes this worse is that it's completely opaque to end users, since this just reports that no node was available to schedule the instance. However, Nova *only* uses the v2 api to list images if the glance.allowed_direct_url_schemes config key is set in the config file. However, this config item defaults to an empty array, meaning that by default it's *always* set. There doesn't appear to be a way to unset a value with oslo-config that has a default value, blocking off that route to work around the issue. Disabling the v2 Glance API we don't think will work, since Nova appears to assume the v2 API is available. AFAIK, Nova supports V2 image-lists since before Juno when the allowed_direct_url_schemes config option is set. Are you referring to another change? Has the default been changed in Nova? I'm asking because I was working on this migration to V2 and we decided to postpone it to L. Another work around we've looked at is to change the DB schema for image properties (yuck) to not allow NULL values. This results in Glance returning a 500 error since glance-api is attempting to insert an invalid value. This is better than instances failing in an opaque fashion, but still pretty horrible. Has anyone else run into this issue yet? Are there other work arounds that we've not thought of other than Don't create images with NULL properties? User education is definitely an option, but given the failure mode, it's not a great solution for us. I believe this needs to be fixed in the client rather than the API and/or the schemas. I'll take a look at this right away. Another workaround could be updateting `schema-image.json` to add the schemas that are missing and let the client download the final schema from the V2 API. Keep an eye on the bug, patches coming your way (assuming what I have in mind will work). Flavio -- @flaper87 Flavio Percoco pgpI1F6sCNXfx.pgp Description: 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
Re: [openstack-dev] [horizon][i18n] Ordering of PO files
On 06/09/2015 01:28 AM, Thai Q Tran wrote:
Hi folks,
In the midst of shifting to angular, we are making use of babel for
extracting messages. This would then allow us to write a custom
extractor for angular templates.
Here's the patch that compare PO files:
https://review.openstack.org/#/c/189502/
It looks worse than reality, if you compare the django vs babel
makemessages, they are nearly identical, only the ordering is different.
Which leads me to my next point. If the ordering of the translatable
strings are not the same, how does that affect translation (if at all)?
It doesn't.
Our tools always sort the entries, we call for all files:
msgattrib --translated --no-location --sort-output $i \
--output=${i}.tmp
Please use the same commands for generation as our tools. For horizon
see
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/propose_translation_update_horizon.sh
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
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] [Ironic] [Inspector] Toward 2.0.0 release
On 06/09/2015 03:49 AM, Yuiko Takada wrote: Hi, Dmitry, Thank you for notifying. I've updated our summit etherpad [3] with whatever priorities I remembered, please have a look. I've also untargeted a few things in launchpad [4] (and will probably untarget more later on). Please assign yourself, if you want something done in this release time frame. I've assigned one item to myself in [3], and also I added one BP to [4], so please take a look. https://blueprints.launchpad.net/ironic-inspector/+spec/delete-db-api Looks good, though I don't think it's a big priority for 2.0.0. Definitely worth doing for 2.1.0. Thanks for assigning for tempest work, that's definitely a priority right now. BTW, how do you think about Ironic-inspector's release model? You wrote Version released with Ironic Liberty as Ironic-inspector Version 2.1.0 in etherpad [3], but as you know, Ironic's release model has changed to feature releases.(right?) Should we make our release model same as Ironic? I guess the whole idea of new release models is NOT to tie projects to each other any more except for The Big Release twice a year :) So I think no, we don't need to. We still can do it, if we have something to release by the time Ironic releases, but I suggest deciding it on case-by-case basis. Best Regards, Yuiko Takada(Inspector team member) 2015-06-08 20:38 GMT+09:00 Dmitry Tantsur dtant...@redhat.com mailto:dtant...@redhat.com: Hello, Inspector team! The renaming process is going pretty well, the last thing we need to do is to get Infra approval and actual rename [1][2]. I'd like to allow people (e.g. myself) to start packaging inspector under it's new name, so I'd like to make 2.0.0 release as soon as possible (as opposed to scheduling it to particular date). All breaking changes should land by this release - I don't expect 3.0.0 soon :) I've updated our summit etherpad [3] with whatever priorities I remembered, please have a look. I've also untargeted a few things in launchpad [4] (and will probably untarget more later on). Please assign yourself, if you want something done in this release time frame. I would like 2.1.0 to be released with Ironic Liberty and be properly supported. Let me know what you think. Cheers, Dmitry [1] https://review.openstack.org/#/c/188030/ [2] https://review.openstack.org/#/c/188798/ [3] https://etherpad.openstack.org/p/liberty-ironic-discoverd [4] https://bugs.launchpad.net/ironic-inspector/+milestone/2.0.0 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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] [glance] [nova] Glance bug with Kilo upgrade Nova
Flavio, would a DB script that writes an empty string or NOP or something instead of NULL In the column do the trick? Then the problem degenerates to a new DB upgrade script. Regards Malini -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Monday, June 08, 2015 11:47 PM To: OpenStack Development Mailing List (not for usage questions) Cc: openstack-operat...@lists.openstack.org Subject: Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova On 08/06/15 11:46 -0400, Clayton O'Neill wrote: We tested testing Kilo upgrades in our hardware dev environments last week and the second time through ran into this bug which right now is probably a show-stopper for us. https://bugs.launchpad.net/glance/+bug/1419823 The issue here is that the v1 Glance API allows you to create images with properties that are 'NULL' in the Glance database. For example: glance image-create --name cirros_test --disk-format qcow2 --container-format bare --file cirros-0.3.4-x86_64-disk.img --is-public True --is-protected True --progress --property description= It's apparently also fairly easy to end up with a NULL description when editing images properties via Horizon. The issue is that the v2 Glance API returns these NULL properties to the client, which then validates them against the schema returned by the v2 API. This schema returns specifies that the description property *must* be a string. In the Kilo release, Nova has been changed to use the v2 API, so suddenly this matters. The net effect is that end users can pretty easily create properties with NULL values, and then won't be able to boot instances using those images. What makes this worse is that it's completely opaque to end users, since this just reports that no node was available to schedule the instance. However, Nova *only* uses the v2 api to list images if the glance.allowed_direct_url_schemes config key is set in the config file. However, this config item defaults to an empty array, meaning that by default it's *always* set. There doesn't appear to be a way to unset a value with oslo-config that has a default value, blocking off that route to work around the issue. Disabling the v2 Glance API we don't think will work, since Nova appears to assume the v2 API is available. AFAIK, Nova supports V2 image-lists since before Juno when the allowed_direct_url_schemes config option is set. Are you referring to another change? Has the default been changed in Nova? I'm asking because I was working on this migration to V2 and we decided to postpone it to L. Another work around we've looked at is to change the DB schema for image properties (yuck) to not allow NULL values. This results in Glance returning a 500 error since glance-api is attempting to insert an invalid value. This is better than instances failing in an opaque fashion, but still pretty horrible. Has anyone else run into this issue yet? Are there other work arounds that we've not thought of other than Don't create images with NULL properties? User education is definitely an option, but given the failure mode, it's not a great solution for us. I believe this needs to be fixed in the client rather than the API and/or the schemas. I'll take a look at this right away. Another workaround could be updateting `schema-image.json` to add the schemas that are missing and let the client download the final schema from the V2 API. Keep an eye on the bug, patches coming your way (assuming what I have in mind will work). Flavio -- @flaper87 Flavio Percoco __ 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] New subscriber:choudharyvika...@gmail.com is my email id.
__ 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] [horizon][i18n] Ordering of PO files
Agree with Akihiro. I don't see the order change will affect the translation work. Best regards Ying Chun Guo (Daisy) Akihiro Motoki amot...@gmail.com wrote on 2015/06/09 12:57:59: From: Akihiro Motoki amot...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 2015/06/09 12:59 Subject: Re: [openstack-dev] [horizon][i18n] Ordering of PO files Hi Thai, At the moment, translation effort are done on Transifex, so I think it is not a big problem even if the ordering of translatable strings are changed (as long as the strings themselves are not changed). Even when using the current extractor from Django, the order of translatable strings are sometimes changed, and the ordering is changed after uploading and then downloading translations to/from Transifex. Akihiro 2015-06-09 8:28 GMT+09:00 Thai Q Tran tqt...@us.ibm.com: Hi folks, In the midst of shifting to angular, we are making use of babel for extracting messages. This would then allow us to write a custom extractor for angular templates. Here's the patch that compare PO files: https:// review.openstack.org/#/c/189502/ It looks worse than reality, if you compare the django vs babel makemessages, they are nearly identical, only the ordering is different. Which leads me to my next point. If the ordering of the translatable strings are not the same, how does that affect translation (if at all)? __ 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] [Cinder] Getting `ValueError: Field `volume_id' cannot be None`
Thang,
Thanks! Its still not clear to me why my method doesn't work. FWIW, i did
try db.snapshot_get = mock.Mock(...) before and when that didn't work, i
was just trying out
with remotefs.db.snapshot_get with the assumption that maybe some scope
issue is there hence I should try using the complete path right from
module, but that didn't work either and i guess its still not clear why
a mock in one test module affects another.
Given that mock.patch is working as evident from your patch, i will
continue to use it.
Thanks for helping out.
On Thu, Jun 4, 2015 at 9:21 PM, Thang Pham thang.g.p...@gmail.com wrote:
The problem is in your test case. There is no such methods as
remotefs.db.snapshot_get or remotefs.db.snapshot_admin_metadata_get.
You need to use with mock.patch('cinder.db.snapshot_get') as snapshot_get,
mock.patch('cinder.db.snapshot_admin_metadata_get')
as snapshot_admin_metadata_get. These incorrect calls somehow created a
side effect in the other test cases. I updated you patch with what is
correct, so you should follow it for you other tests. Your test case needs
a lot more work, I just edited it to just have it pass the unit tests.
Thang
On Thu, Jun 4, 2015 at 4:36 AM, Deepak Shetty dpkshe...@gmail.com wrote:
I was able to narrow down to the scenario where it fails only when i do:
./run_tests.sh -N cinder.tests.unit.test_remotefs
cinder.tests.unit.test_volume.VolumeTestCase
and fails with:
{0}
cinder.tests.unit.test_volume.VolumeTestCase.test_can_delete_errored_snapshot
[0.507361s] ... FAILED
Captured traceback:
~~~
Traceback (most recent call last):
File cinder/tests/unit/test_volume.py, line 3029, in
test_can_delete_errored_snapshot
snapshot_obj = objects.Snapshot.get_by_id(self.context,
snapshot_id)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 169,
in wrapper
result = fn(cls, context, *args, **kwargs)
File cinder/objects/snapshot.py, line 130, in get_by_id
expected_attrs=['metadata'])
File cinder/objects/snapshot.py, line 112, in _from_db_object
snapshot[name] = value
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 691,
in __setitem__
setattr(self, name, value)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 70,
in setter
field_value = field.coerce(self, name, value)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/fields.py, line
183, in coerce
return self._null(obj, attr)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/fields.py, line
161, in _null
raise ValueError(_(Field `%s' cannot be None) % attr)
ValueError: Field `volume_id' cannot be None
Both the testsuites run fine when i run them individually, as in the
below is success:
./run_tests.sh -N cinder.tests.unit.test_remotefs - no errors
./run_tests.sh -N cinder.tests.unit.test_volume.VolumeTestCase - no errors
So i modified my patch @ https://review.openstack.org/#/c/172808/ (Patch
set 6) and
removed all testcase i added in test_remotefs.py except one, so that we
have lesser code to debug/deal with!
See
https://review.openstack.org/#/c/172808/6/cinder/tests/unit/test_remotefs.py
Now when i disable test_create_snapshot_online_success then running both
the suites work,
but when i enable test_create_snapshot_online_success then it fails as
above.
I am unable to figure whats the connection between
test_create_snapshot_online_success
in test_remotefs.py
and VolumeTestCase.test_can_delete_errored_snapshot in test_volume.py
failure
Can someone help here ?
thanx,
deepak
On Thu, Jun 4, 2015 at 1:37 PM, Deepak Shetty dpkshe...@gmail.com
wrote:
Hi Thang,
Since you are working on Snapshot Objects, any idea on why the
testcase when run all by itself, works, but when run as part of the overall
suite, fails ?
This seems to be related to the Snapshot Objects, hence Ccing you.
On Wed, Jun 3, 2015 at 9:54 PM, Deepak Shetty dpkshe...@gmail.com
wrote:
Hi All,
I am hitting a strange issue when running Cinder unit tests against
my patch @
https://review.openstack.org/#/c/172808/5
I have spent 1 day and haven't been successfull at figuring how/why my
patch is causing it!
All tests failing are part of VolumeTestCase suite and from the error
(see below) it seems
the Snapshot Object is complaining that 'volume_id' field is null
(while it shouldn't be)
An example error from the associated Jenkins run can be seen @
http://logs.openstack.org/08/172808/5/check/gate-cinder-python27/0abd15e/console.html.gz#_2015-05-22_13_28_47_140
I am seeing a total of 21 such errors.
Its strange because, when I try to reproduce it locally in my devstack
env, I see the below:
1) When i just run: ./run_tests.sh -N cinder.tests.unit.test_volume.
VolumeTestCase
all testcases pass
2) When i run 1 individual
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Sent via mobile
On Jun 9, 2015, at 05:44, Jamie Lennox jamielen...@redhat.com wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk
To: openstack-dev@lists.openstack.org
Sent: Saturday, 6 June, 2015 6:01:10 PM
Subject: Re: [openstack-dev] [keystone][reseller] New way to get a project
scoped token by name
On 06/06/2015 00:24, Adam Young wrote:
On 06/05/2015 01:15 PM, Henry Nash wrote:
I am sure I have missed something along the way, but can someone
explain to me why we need this at all. Project names are unique
within a domain, with the exception of the project that is acting as
its domain (i.e. they can only every be two names clashing in a
hierarchy at the domain level and below). So why isn’t specifying
“is_domain=True/False” sufficient in an auth scope along with the
project name?
The limitation of Project names are unique within a domain is
artificial and somethi8ng we should not be enforcing. Names should only
be unique within parent project.
+++1
I said the exact same thing as Henry in the other thread that seems to be on
the same topic. You're correct the limitation of Project names are unique
within a domain is completely artificial, but it's a constraint that allows
us to maintain the auth systems we currently have and will not harm the
reseller model (because they would be creating new domains).
It's also a constraint that we can relax later when multitenancy is a bit
more established and someone has a real issue with the limitation - it's not
something we can ever claw back again if we allow some looking up projects by
name with delimiters.
I think for the time being it's an artificial constraint we should maintain.
+1
This whole thing started by trying to distinguish a domain from a
project within that domain that both have the same name. We can special
case that, but it is not a great solution.
Henry
On 5 Jun 2015, at 18:02, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well
more to the point there should be a common one across OpenStack
installations to ensure we are providing a good and consistent (and
more to the point inter-operable) experience to our users. I'm
worried a custom defined delimiter (even at the domain level) is
going to make it difficult to consume this data outside of the
context of OpenStack (there are applications that are written to use
the APIs directly).
We have one already. We are working JSON, and so instead of project
name being a string, it can be an array.
Nothing else is backwards compatible. Nothing else will ensure we
don;t break exisiting deployments.
Moving forward, we should support DNS notation, but it has to be an
opt in
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy: {delim: ., domain.project.project2}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not
solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would
define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we
want a
domain, we
should always reference the namespace as we do today.
Basically, if we
ask for a project name we need to also provide it's
namespace (your
option #1). This clearly lines up with how we handle
projects in
domains
today.
I would, however, focus on how to represent the
namespace in a single
(usable) string. We've been delaying the work on this
for a while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter
between domain,
project, and subdomain/subproject, we end up solving the
usability
why not allow the top level domain/project to define the
delimiter for
its tree, and to carry the delimiter in the JSON as a new
parameter.
Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova
On 09/06/15 07:09 +, Bhandaru, Malini K wrote: Flavio, would a DB script that writes an empty string or NOP or something instead of NULL In the column do the trick? Then the problem degenerates to a new DB upgrade script. I now remembered about a change[0] - that I wrote myself - that required a bump on the API version - which we did - that allows None values to be returned in the API. This is probably what is causing this behavior. A DB migration would certainly work, I'd love to avoid it but I guess that's the best solution in this case. Cheers, Flavio [0] https://review.openstack.org/#/c/138184/ Regards Malini -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Monday, June 08, 2015 11:47 PM To: OpenStack Development Mailing List (not for usage questions) Cc: openstack-operat...@lists.openstack.org Subject: Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova On 08/06/15 11:46 -0400, Clayton O'Neill wrote: We tested testing Kilo upgrades in our hardware dev environments last week and the second time through ran into this bug which right now is probably a show-stopper for us. https://bugs.launchpad.net/glance/+bug/1419823 The issue here is that the v1 Glance API allows you to create images with properties that are 'NULL' in the Glance database. For example: glance image-create --name cirros_test --disk-format qcow2 --container-format bare --file cirros-0.3.4-x86_64-disk.img --is-public True --is-protected True --progress --property description= It's apparently also fairly easy to end up with a NULL description when editing images properties via Horizon. The issue is that the v2 Glance API returns these NULL properties to the client, which then validates them against the schema returned by the v2 API. This schema returns specifies that the description property *must* be a string. In the Kilo release, Nova has been changed to use the v2 API, so suddenly this matters. The net effect is that end users can pretty easily create properties with NULL values, and then won't be able to boot instances using those images. What makes this worse is that it's completely opaque to end users, since this just reports that no node was available to schedule the instance. However, Nova *only* uses the v2 api to list images if the glance.allowed_direct_url_schemes config key is set in the config file. However, this config item defaults to an empty array, meaning that by default it's *always* set. There doesn't appear to be a way to unset a value with oslo-config that has a default value, blocking off that route to work around the issue. Disabling the v2 Glance API we don't think will work, since Nova appears to assume the v2 API is available. AFAIK, Nova supports V2 image-lists since before Juno when the allowed_direct_url_schemes config option is set. Are you referring to another change? Has the default been changed in Nova? I'm asking because I was working on this migration to V2 and we decided to postpone it to L. Another work around we've looked at is to change the DB schema for image properties (yuck) to not allow NULL values. This results in Glance returning a 500 error since glance-api is attempting to insert an invalid value. This is better than instances failing in an opaque fashion, but still pretty horrible. Has anyone else run into this issue yet? Are there other work arounds that we've not thought of other than Don't create images with NULL properties? User education is definitely an option, but given the failure mode, it's not a great solution for us. I believe this needs to be fixed in the client rather than the API and/or the schemas. I'll take a look at this right away. Another workaround could be updateting `schema-image.json` to add the schemas that are missing and let the client download the final schema from the V2 API. Keep an eye on the bug, patches coming your way (assuming what I have in mind will work). Flavio -- @flaper87 Flavio Percoco -- @flaper87 Flavio Percoco pgprV77sxIp_G.pgp Description: 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
Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova
A DB migrate script that puts some token default string only for glance properties that are NULL. Should not change anything else. Hope it works Flavio. Regards Malini -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Tuesday, June 09, 2015 12:33 AM To: Bhandaru, Malini K Cc: OpenStack Development Mailing List (not for usage questions); openstack-operat...@lists.openstack.org Subject: Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova On 09/06/15 09:22 +0200, Flavio Percoco wrote: On 09/06/15 07:09 +, Bhandaru, Malini K wrote: Flavio, would a DB script that writes an empty string or NOP or something instead of NULL In the column do the trick? Then the problem degenerates to a new DB upgrade script. I now remembered about a change[0] - that I wrote myself - that required a bump on the API version - which we did - that allows None values to be returned in the API. This is probably what is causing this behavior. A DB migration would certainly work, I'd love to avoid it but I guess that's the best solution in this case. Actually, we can't just migrate the database as there might be custom properties that were explicitly set to None. I'll keep you posted Cheers, Flavio [0] https://review.openstack.org/#/c/138184/ Regards Malini -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Monday, June 08, 2015 11:47 PM To: OpenStack Development Mailing List (not for usage questions) Cc: openstack-operat...@lists.openstack.org Subject: Re: [openstack-dev] [glance] [nova] Glance bug with Kilo upgrade Nova On 08/06/15 11:46 -0400, Clayton O'Neill wrote: We tested testing Kilo upgrades in our hardware dev environments last week and the second time through ran into this bug which right now is probably a show-stopper for us. https://bugs.launchpad.net/glance/+bug/1419823 The issue here is that the v1 Glance API allows you to create images with properties that are 'NULL' in the Glance database. For example: glance image-create --name cirros_test --disk-format qcow2 --container-format bare --file cirros-0.3.4-x86_64-disk.img --is-public True --is-protected True --progress --property description= It's apparently also fairly easy to end up with a NULL description when editing images properties via Horizon. The issue is that the v2 Glance API returns these NULL properties to the client, which then validates them against the schema returned by the v2 API. This schema returns specifies that the description property *must* be a string. In the Kilo release, Nova has been changed to use the v2 API, so suddenly this matters. The net effect is that end users can pretty easily create properties with NULL values, and then won't be able to boot instances using those images. What makes this worse is that it's completely opaque to end users, since this just reports that no node was available to schedule the instance. However, Nova *only* uses the v2 api to list images if the glance.allowed_direct_url_schemes config key is set in the config file. However, this config item defaults to an empty array, meaning that by default it's *always* set. There doesn't appear to be a way to unset a value with oslo-config that has a default value, blocking off that route to work around the issue. Disabling the v2 Glance API we don't think will work, since Nova appears to assume the v2 API is available. AFAIK, Nova supports V2 image-lists since before Juno when the allowed_direct_url_schemes config option is set. Are you referring to another change? Has the default been changed in Nova? I'm asking because I was working on this migration to V2 and we decided to postpone it to L. Another work around we've looked at is to change the DB schema for image properties (yuck) to not allow NULL values. This results in Glance returning a 500 error since glance-api is attempting to insert an invalid value. This is better than instances failing in an opaque fashion, but still pretty horrible. Has anyone else run into this issue yet? Are there other work arounds that we've not thought of other than Don't create images with NULL properties? User education is definitely an option, but given the failure mode, it's not a great solution for us. I believe this needs to be fixed in the client rather than the API and/or the schemas. I'll take a look at this right away. Another workaround could be updateting `schema-image.json` to add the schemas that are missing and let the client download the final schema from the V2 API. Keep an eye on the bug, patches coming your way (assuming what I have in mind will work). Flavio -- @flaper87 Flavio Percoco -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [ceilometer] polling agent configuration speculation
A couple things about this seem less than ideal: * 2 means we load redundant stuff unless we edit entry_points.txt. We do not want to encourage this sort of behavior. entry_points is not configuration[1]. We should configure elsewhere to declare I care about things X (including the option of all things) and then load the tools to do so, on demand. * Two things are happening in the same context in step 5 and that seems quite limiting with regard to opportunities for effective maintenance and optimizing. My intuition (which often needs to sanity checked, thus my posting here) tells me there are some things we could change: * Separate polling and publishing/transforming into separate workers/processes. * Extract the definition of sources to be polled from pipeline.yaml to its own file and use that to be the authority of which extensions are loaded for polling and discovery. i still like the idea of splitting polling and processing task. pros: - it moves load off poll agents and onto notificaiton agent - we essentially get free healthcheck events by doing this con: to play devil's advocate. the one down side is that now there's two levels of filtering (something we also ran into for declarative meters.) in notification agents we first define which exchanges we want to listen to, and then we also define which event_types we want to build off of. similarly, here define what you want to poll, and then in notification agent, you define what you want to build. so now you need to ensure what you're polling matches up with what you want to build (ie. you're polling the right things to build the data you want or you're not polling stuff you don't intend to poll)... this may or may not be a huge issue but it may be confusing to some. that said, i don't see this being any different from users configuring notifications in cinder/nova/etc... and matching that configuration to what ceilometer is configured to build. cheers, gord __ 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] [cinder] Port Cinder to Python 3
Hi, Le 26/05/2015 11:51, Duncan Thomas a écrit : Thanks Victor, that is pretty much exactly what I wanted to hear - there's a known, finite plan to get us to fully working with python3. I'll go change my reviews now. As expected, two weeks later, all my patches are in conflict :-) I rebased my Python 3 patches for Cinder: https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:py3,n,z In the meantime, I enhanced my sixer tool, so the generated patches are larger but fixes more code. I splitted the six.moves patch into 3 patches: six.moves, StringIO and urllib. Can someone please review them to not have to rebase them every 2 weeks? ;-) Thanks, Victor __ 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] [oslo.vmware] Bump oslo.vmware to 1.0.0
Gary, Tracy, Vipin and other contributors, Is oslo.vmware API solid enough for us to bump to 1.0.0? if not, what's left to be done? thanks, dims -- Davanum Srinivas :: https://twitter.com/dims __ 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] [Murano] python-openstackclient support
Since it includes a certain research phase (on how to integrate properly) I’d bet on half-a-week to week of work. But that’s just a wild guess. Might be less, might be more. -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 9 Jun 2015 at 14:59:13, Ekaterina Chernova (efedor...@mirantis.com) wrote: Hi all! I support the idea! Kirill, how much time do you think blueprint implementation will take? On Tue, Jun 9, 2015 at 2:46 PM, Kirill Zaitsev kzait...@mirantis.com wrote: https://blueprints.launchpad.net/python-muranoclient/+spec/openstack-client-plugin-support I’ve done that a while ago, already =). Could you please approve it? -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 9 Jun 2015 at 11:45:56, Serg Melikyan (smelik...@mirantis.com) wrote: Hi Kirill, It's definitely a great idea, it needs to be verified though AFAIK all openstack projects are moving to support python-openstackclient. I think we should file a blueprint around that and start looking at that on background. I think it will be not a big deal to support python-openstackclient. On Thu, Apr 23, 2015 at 3:04 AM, Stan Lagun sla...@mirantis.com wrote: +1 for the idea though not sure on priority of this since we have so many way more important things to implement in Kilo. I'd say that would be a great contribution if we find someone willing to contribute it :) Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Thu, Apr 23, 2015 at 1:55 AM, Kirill Zaitsev kzait...@mirantis.com wrote: Since python-openstackclient is now a part of openstack — I guess it would be a good idea to support it in murano. It has setuptools-based plugin system, and it should be fairly easy to add murano commands as plugins to it. BTW, It’s based on cliff and has a terrific completion support (which is basically why I started looking into the issue in the first place =)) What do you think, is it a good idea? -- Kirill Zaitsev Sent with Airmail __ 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 -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ 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 __ 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] Liberty Priorties for Nova
On 06/09/2015 10:28 AM, Daniel P. Berrange wrote: On Tue, Jun 09, 2015 at 03:07:51PM +0100, Neil Jerram wrote: Secondly there is the VIF plug script idea, and it's here that the elephant may be. I'm afraid that some of the interested people (including me) missed it, but I heard that the core team discussed this and expressed concern, in one of the Vancouver sessions, about 'not wanting Nova to become a pass-through API'. Since then, spec work has continued, but the only core input has come from Dan PB, who wasn't in that Vancouver session - so I'm worried that the Nova core team as a whole might not support this idea, and that the ongoing spec refinement might turn out to be rearranging the deck chairs on the Titanic. As you said, I wasn't there, so I don't know what the objections were, but I'm personally not supportive of adding any new VIF types until we have the VIF plugging script work done. This concept is critical to preventing the further explosion in the number of VIF types we need, and in allowing vendors to add new neutron mechanisms without always requiring a lock-step update to Nova. So from that POV I think the VIF script thing needs to be the #1 priority wrt VIF driver work in Nova/libvirt for Liberty. FTR, here is the VIF plugin script spec in Nova: https://review.openstack.org/#/c/162468/13/specs/liberty/approved/vif-plug-script.rst Best, -jay __ 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] [release][oslo] oslosphinx release 3.0.0 (liberty)
We are glad to announce the release of: oslosphinx 3.0.0: OpenStack Sphinx Extensions and Theme This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslosphinx For more details, please see the git log history below and: http://launchpad.net/oslosphinx/+milestone/3.0.0 Please report issues through launchpad: http://bugs.launchpad.net/oslosphinx Changes in oslosphinx 2.5.0..3.0.0 -- 46832a8 Drop incubating theme option f14ad41 Replace ci.o.o links with docs.o.o/infra 495aec3 Advertise support for Python3.4 / Remove support for Python 3.3 d79b8cc Updated from global requirements 90a1e5d Remove run_cross_tests.sh 6e76e42 Updated from global requirements 33845ab Remove the unneeded horizontal scrollbar 7ddfe1c Adds javascript footer for Google Analytics tracking 199235c Update to latest hacking Diffstat (except docs and test files) - openstack-common.conf | 3 - oslosphinx/intersphinx.py | 4 +- oslosphinx/theme/openstack/layout.html | 19 +- oslosphinx/theme/openstack/static/basic.css | 1 - requirements.txt| 4 +- setup.cfg | 2 +- test-requirements.txt | 2 +- 8 files changed, 22 insertions(+), 113 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 19d3ae5..cc4784c 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5,2 +5,2 @@ -pbr=0.6,!=0.7,1.0 -requests=2.2.0,!=2.4.0 +pbr=0.11,2.0 +requests=2.5.2 diff --git a/test-requirements.txt b/test-requirements.txt index b859e83..cda046a 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -5 +5 @@ -hacking=0.9.2,0.10 +hacking=0.10.0,0.11 __ 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] [release][oslo] oslo.log release 1.4.0 (liberty)
We are thrilled to announce the release of: oslo.log 1.4.0: oslo.log library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.log For more details, please see the git log history below and: http://launchpad.net/oslo.log/+milestone/1.4.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.log Changes in oslo.log 1.3.0..1.4.0 8578bdd Allow integer logging levels Diffstat (except docs and test files) - oslo_log/log.py | 19 --- 2 files changed, 20 insertions(+), 3 deletions(-) __ 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] [release][oslo] oslo.vmware release 0.14.0 (liberty)
We are amped to announce the release of: oslo.vmware 0.14.0: Oslo VMware library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.14.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.13.1..0.14.0 - 7ebc48c Remove oslo namespace package f2dc3a9 Port test from Nova ee84558 Imported Translations from Transifex Diffstat (except docs and test files) - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 12 +- oslo/__init__.py | 13 - oslo/vmware/__init__.py | 26 -- oslo/vmware/api.py | 13 - oslo/vmware/constants.py | 13 - oslo/vmware/exceptions.py| 13 - oslo/vmware/image_transfer.py| 13 - oslo/vmware/objects/__init__.py | 0 oslo/vmware/objects/datacenter.py| 13 - oslo/vmware/objects/datastore.py | 13 - oslo/vmware/pbm.py | 13 - oslo/vmware/rw_handles.py| 13 - oslo/vmware/service.py | 13 - oslo/vmware/vim.py | 13 - oslo/vmware/vim_util.py | 13 - setup.cfg| 4 - 30 files changed, 44 insertions(+), 3166 deletions(-) __ 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] [release][oslo] oslo.rootwrap release 2.0.0 (liberty)
We are glad to announce the release of: oslo.rootwrap 2.0.0: Oslo Rootwrap This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.rootwrap For more details, please see the git log history below and: http://launchpad.net/oslo.rootwrap/+milestone/2.0.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.rootwrap Changes in oslo.rootwrap 1.8.0..2.0.0 - 8a6c9af Remove oslo namespace package b786a77 Generate a oslo-rootwrap console script Diffstat (except docs and test files) - oslo/__init__.py | 13 - oslo/rootwrap/__init__.py | 26 -- oslo/rootwrap/client.py | 13 - oslo/rootwrap/cmd.py | 13 - oslo/rootwrap/daemon.py | 13 - oslo/rootwrap/filters.py | 13 - oslo/rootwrap/jsonrpc.py | 13 - oslo/rootwrap/wrapper.py | 13 - setup.cfg | 9 +- 15 files changed, 5 insertions(+), 1080 deletions(-) __ 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] [all] [stable] No longer doing stable point releases
On 2015-06-09 10:55:55 +0200 (+0200), Thomas Goirand wrote: [...] That's far from being in place. Also, while we are removing point releases, and support for Icehouse, we still don't have a common private Gerrit for security, which we've been told about 2 years ago. Removing collaboration tools before new ones are in place is definitively not the way to go. [...] In the stable branch management session at the Liberty summit, the Infrastructure Team position was confirmed that we can't maintain non-supported branches in a second Gerrit any more than we can in the primary one. The idea that there might be some branch of an OpenStack project which we just give up on testing but keep available for new changes is distasteful from a quality perspective. If there is sufficient interest from distro representatives in collaborating upstream on backports to, for example, stable/icehouse then that interest needs to include the resources necessary to maintain sufficient testing upstream (as defined by the upstream community). So, I'm sorry, but don't look to an OpenStack-maintained non-public code review system as a workaround for continuing to collaborate in private on branches unsupported upstream in public. Most of the time it ends up being non-distro upstream developers (quality assurance, release management, infrastructure, vulnerability management, individual projects) who bear the majority of the responsibility for keeping testing working on those branches and we're clearly at our breaking point now trying to maintain three besides our master branch. If the interested distributions come back with teams of people to dedicate to this work, which means getting deeply embedded in the groups who currently maintain the existing testing and release management for stable branches and are currently understaffed for that effort, then we can certainly revisit the number of branches we're able to maintain in both the public and (future) embargoed security review systems. -- Jeremy Stanley signature.asc Description: Digital 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-dev] [release][oslo] oslo.middleware release 2.0.0 (liberty)
We are excited to announce the release of: oslo.middleware 2.0.0: Oslo Middleware library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.middleware For more details, please see the git log history below and: http://launchpad.net/oslo.middleware/+milestone/2.0.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.middleware Changes in oslo.middleware 1.3.0..2.0.0 --- bcbfceb Remove oslo namespace package Diffstat (except docs and test files) - oslo/__init__.py | 13 - oslo/middleware/__init__.py | 28 -- oslo/middleware/base.py | 13 - oslo/middleware/catch_errors.py | 13 - oslo/middleware/correlation_id.py | 13 - oslo/middleware/debug.py | 13 - oslo/middleware/request_id.py | 13 - oslo/middleware/sizelimit.py | 13 - setup.cfg | 4 -- 15 files changed, 429 deletions(-) __ 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] [release][oslo] oslo.policy release 0.6.0 (liberty)
We are glad to announce the release of: oslo.policy 0.6.0: Oslo Policy library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.policy For more details, please see the git log history below and: http://launchpad.net/oslo.policy/+milestone/0.6.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.policy Changes in oslo.policy 0.5.0..0.6.0 --- b8401f2 Fix Enforcer docstring c586dae Cleanup logging to conform to guidelines 1e7b597 Cleanup logging to conform to guidelines 3474d07 Remove support for Python 3.3 729cb27 Updated from global requirements Diffstat (except docs and test files) - oslo_policy/_parser.py| 6 +++--- oslo_policy/openstack/common/fileutils.py | 2 +- oslo_policy/policy.py | 4 ++-- requirements.txt | 2 +- setup.cfg | 1 - 5 files changed, 7 insertions(+), 8 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 1d780b2..86e5a54 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -oslo.config=1.9.3 # Apache-2.0 +oslo.config=1.11.0 # Apache-2.0 __ 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] [Murano] Virtual Mid-Cycle Summit - Overview Day
Hi folks, We discussed [0] previously that we need a some kind of mid-cycle summit in order to discuss blueprints and feature for Liberty that we were not able to discuss at the OpenStack Summit in Vancouver partially due to some contributors were not able to attend and partially because Summit agenda was really packed. We agreed that best way to do that is to start with one-day virtual mid-cycle summit using some video-conference software (WebEx? [1]) and extend it if needed. I've created doodle [2] - let's choose date/time for our virtual mid-cycle summit! Please, propose agenda for mid-cycle summit using etherpad: https://etherpad.openstack.org/p/murano-liberty-virtual-summit References: [0] http://eavesdrop.openstack.org/meetings/murano/2015/murano.2015-05-26-17.02.log.html [1] http://www.webex.com/ [2] http://doodle.com/awyqduy5a94x45zz -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com __ 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] [Congress] summit events
Hi Joe, The telco slides are powerpoint, but are hosted on google drive: https://docs.google.com/a/styra.com/file/d/0ByDz-eYOtswScUFUc1ZrVVhmQlk/edit The slides themselves may not include all the content you want without the soundtrack. Here's the corresponding design doc. https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit Both these links are now on the Congress wiki as well. Tim On Tue, Jun 9, 2015 at 5:53 AM D'ANDREA, JOE (JOE) jdand...@research.att.com wrote: Tim, I really appreciated the Intro/Status talk, and I'm sorry to have missed the Telco talk. Are slides for those talks available online? On May 12, 2015, at 1:34 PM, Tim Hinrichs thinri...@vmware.com wrote: (On delegation) Helping Telcos go Green and save OpEx via Policy Wed, May 20 2:40-3:20, Room 110 https://libertydesignsummit.sched.org/event/e449fb7aca1e5d8da3a555ef03c535a9#.VUOcf61VhBc (Overview) Congress: Introduction, Status, and Future Plans Thu, May 21 3:10-3:50, Room 306 https://libertydesignsummit.sched.org/event/c64db4197dfd158458e3dd59f223a6e5#.VUOcRq1VhBc jd — Joe D’Andrea ATT Labs - Research Cloud Technologies Services Bedminster, NJ __ 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] [Cinder] Getting `ValueError: Field `volume_id' cannot be None`
Thangp,
I have a related Question wrt your comment in
https://review.openstack.org/#/c/172808/6/cinder/api/contrib/snapshot_actions.py
Do i need to add support for snapshot_admin_metadata table in
object/snapshot.py or I need to create
a new object since its a new table, I am not clear on this, can you let me
know pls ?
ALternatively I am fine if you want to collaborate on my patch and add
snapshot_admin_metadata object support too ?
Let me know pls
thanx,
deepak
On Tue, Jun 9, 2015 at 12:12 PM, Deepak Shetty dpkshe...@gmail.com wrote:
Thang,
Thanks! Its still not clear to me why my method doesn't work. FWIW, i
did try db.snapshot_get = mock.Mock(...) before and when that didn't work,
i was just trying out
with remotefs.db.snapshot_get with the assumption that maybe some scope
issue is there hence I should try using the complete path right from
module, but that didn't work either and i guess its still not clear why
a mock in one test module affects another.
Given that mock.patch is working as evident from your patch, i will
continue to use it.
Thanks for helping out.
On Thu, Jun 4, 2015 at 9:21 PM, Thang Pham thang.g.p...@gmail.com wrote:
The problem is in your test case. There is no such methods as
remotefs.db.snapshot_get or remotefs.db.snapshot_admin_metadata_get.
You need to use with mock.patch('cinder.db.snapshot_get') as snapshot_get,
mock.patch('cinder.db.snapshot_admin_metadata_get')
as snapshot_admin_metadata_get. These incorrect calls somehow created a
side effect in the other test cases. I updated you patch with what is
correct, so you should follow it for you other tests. Your test case needs
a lot more work, I just edited it to just have it pass the unit tests.
Thang
On Thu, Jun 4, 2015 at 4:36 AM, Deepak Shetty dpkshe...@gmail.com
wrote:
I was able to narrow down to the scenario where it fails only when i do:
./run_tests.sh -N cinder.tests.unit.test_remotefs
cinder.tests.unit.test_volume.VolumeTestCase
and fails with:
{0}
cinder.tests.unit.test_volume.VolumeTestCase.test_can_delete_errored_snapshot
[0.507361s] ... FAILED
Captured traceback:
~~~
Traceback (most recent call last):
File cinder/tests/unit/test_volume.py, line 3029, in
test_can_delete_errored_snapshot
snapshot_obj = objects.Snapshot.get_by_id(self.context,
snapshot_id)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 169,
in wrapper
result = fn(cls, context, *args, **kwargs)
File cinder/objects/snapshot.py, line 130, in get_by_id
expected_attrs=['metadata'])
File cinder/objects/snapshot.py, line 112, in _from_db_object
snapshot[name] = value
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 691,
in __setitem__
setattr(self, name, value)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 70,
in setter
field_value = field.coerce(self, name, value)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/fields.py, line
183, in coerce
return self._null(obj, attr)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/fields.py, line
161, in _null
raise ValueError(_(Field `%s' cannot be None) % attr)
ValueError: Field `volume_id' cannot be None
Both the testsuites run fine when i run them individually, as in the
below is success:
./run_tests.sh -N cinder.tests.unit.test_remotefs - no errors
./run_tests.sh -N cinder.tests.unit.test_volume.VolumeTestCase - no
errors
So i modified my patch @ https://review.openstack.org/#/c/172808/
(Patch set 6) and
removed all testcase i added in test_remotefs.py except one, so that we
have lesser code to debug/deal with!
See
https://review.openstack.org/#/c/172808/6/cinder/tests/unit/test_remotefs.py
Now when i disable test_create_snapshot_online_success then running
both the suites work,
but when i enable test_create_snapshot_online_success then it fails as
above.
I am unable to figure whats the connection between
test_create_snapshot_online_success
in test_remotefs.py
and VolumeTestCase.test_can_delete_errored_snapshot in test_volume.py
failure
Can someone help here ?
thanx,
deepak
On Thu, Jun 4, 2015 at 1:37 PM, Deepak Shetty dpkshe...@gmail.com
wrote:
Hi Thang,
Since you are working on Snapshot Objects, any idea on why the
testcase when run all by itself, works, but when run as part of the overall
suite, fails ?
This seems to be related to the Snapshot Objects, hence Ccing you.
On Wed, Jun 3, 2015 at 9:54 PM, Deepak Shetty dpkshe...@gmail.com
wrote:
Hi All,
I am hitting a strange issue when running Cinder unit tests against
my patch @
https://review.openstack.org/#/c/172808/5
I have spent 1 day and haven't been successfull at figuring how/why my
patch is causing it!
All tests failing are part of VolumeTestCase suite and from the error
(see
[openstack-dev] [release][oslo] oslo.messaging release 1.14.0 (liberty)
We are gleeful to announce the release of: oslo.messaging 1.14.0: Oslo Messaging API With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.14.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messaging Changes in oslo.messaging 1.13.0..1.14.0 3044abb Reduce `magic` conf attribute usage 9f146bc Imported Translations from Transifex 94bb8ad Remove leftover oslo.config reference a0b33a4 replace rpc_response_timeout use in rabbit driver 91dd104 Enable `fanout_target` scenarios in test_impl_rabbit bc6e2a8 rabbit: test for new reply behavior fa2a501 Set places to 0 in self.assertAlmostEqual() Diffstat (except docs and test files) - .../locale/fr/LC_MESSAGES/oslo.messaging.po| 40 +- oslo_messaging/_drivers/base.py| 2 +- oslo_messaging/_drivers/impl_rabbit.py | 158 - 4 files changed, 154 insertions(+), 92 deletions(-) __ 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] Liberty Priorties for Nova
On 09/06/15 15:28, Daniel P. Berrange wrote: On Tue, Jun 09, 2015 at 03:07:51PM +0100, Neil Jerram wrote: Secondly there is the VIF plug script idea, and it's here that the elephant may be. I'm afraid that some of the interested people (including me) missed it, but I heard that the core team discussed this and expressed concern, in one of the Vancouver sessions, about 'not wanting Nova to become a pass-through API'. Since then, spec work has continued, but the only core input has come from Dan PB, who wasn't in that Vancouver session - so I'm worried that the Nova core team as a whole might not support this idea, and that the ongoing spec refinement might turn out to be rearranging the deck chairs on the Titanic. As you said, I wasn't there, so I don't know what the objections were, but I'm personally not supportive of adding any new VIF types until we have the VIF plugging script work done. This concept is critical to preventing the further explosion in the number of VIF types we need, and in allowing vendors to add new neutron mechanisms without always requiring a lock-step update to Nova. So from that POV I think the VIF script thing needs to be the #1 priority wrt VIF driver work in Nova/libvirt for Liberty. Thanks for such a quick and clear steer, Dan! So, the next thing is that we really need to understand that 'not wanting Nova to become a pass-through API' concern that was reportedly expressed by other core team members in Vancouver. What was that concern, and does it apply to the VIF script spec [1] as it is now? Thanks, Neil [1] https://review.openstack.org/#/c/162468/ __ 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] [release][oslo] oslo.db release 1.11.0 (liberty)
We are excited to announce the release of: oslo.db 1.11.0: Oslo Database library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.db For more details, please see the git log history below and: http://launchpad.net/oslo.db/+milestone/1.11.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.db Changes in oslo.db 1.10.0..1.11.0 - e0f0608 Replace utils method with oslo.utils reflection provided one 42de3f6 Allow to fail instead of skip in DbFixture Diffstat (except docs and test files) - oslo_db/sqlalchemy/test_base.py | 19 ++- oslo_db/sqlalchemy/utils.py | 25 - 2 files changed, 14 insertions(+), 30 deletions(-) __ 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] [release][oslo][stable] oslo.messaging release 1.8.3 (kilo)
We are satisfied to announce the release of: oslo.messaging 1.8.3: Oslo Messaging API With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.8.3 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messaging Changes in oslo.messaging 1.8.2..1.8.3 -- b5e1583 Adding Publisher Acknowledgements/confirms 41d0d87 consumer connections not closed properly 2daf4dc rabbit: Set timeout on the underlying socket d416889 Updated from global requirements Diffstat (except docs and test files) - oslo_messaging/_drivers/impl_rabbit.py | 333 --- requirements-py3.txt | 12 +- requirements.txt | 14 +- test-requirements-py3.txt| 4 +- test-requirements.txt| 6 +- 6 files changed, 205 insertions(+), 180 deletions(-) Requirements updates diff --git a/requirements-py3.txt b/requirements-py3.txt index 05cb050..75d708c 100644 --- a/requirements-py3.txt +++ b/requirements-py3.txt @@ -5,5 +5,5 @@ -oslo.config=1.9.0 # Apache-2.0 -oslo.serialization=1.2.0 # Apache-2.0 -oslo.utils=1.2.0 # Apache-2.0 -oslo.i18n=1.3.0 # Apache-2.0 -stevedore=1.1.0 # Apache-2.0 +oslo.config=1.9.3,1.10.0 # Apache-2.0 +oslo.serialization=1.4.0,1.5.0 # Apache-2.0 +oslo.utils=1.4.0,1.5.0 # Apache-2.0 +oslo.i18n=1.5.0,1.6.0 # Apache-2.0 +stevedore=1.3.0,1.4.0 # Apache-2.0 @@ -21 +21 @@ kombu=2.5.0 -oslo.middleware=0.3.0 # Apache-2.0 +oslo.middleware=1.0.0,1.1.0 # Apache-2.0 diff --git a/requirements.txt b/requirements.txt index 4e87ee6..58652ef 100644 --- a/requirements.txt +++ b/requirements.txt @@ -7,5 +7,5 @@ pbr=0.6,!=0.7,1.0 -oslo.config=1.9.0 # Apache-2.0 -oslo.utils=1.2.0 # Apache-2.0 -oslo.serialization=1.2.0 # Apache-2.0 -oslo.i18n=1.3.0 # Apache-2.0 -stevedore=1.1.0 # Apache-2.0 +oslo.config=1.9.3,1.10.0 # Apache-2.0 +oslo.utils=1.4.0,1.5.0 # Apache-2.0 +oslo.serialization=1.4.0,1.5.0 # Apache-2.0 +oslo.i18n=1.5.0,1.6.0 # Apache-2.0 +stevedore=1.3.0,1.4.0 # Apache-2.0 @@ -19 +19 @@ six=1.9.0 -eventlet=0.16.1 +eventlet=0.16.1,!=0.17.0 @@ -29 +29 @@ kombu=2.5.0 -oslo.middleware=0.3.0 # Apache-2.0 +oslo.middleware=1.0.0,1.1.0 # Apache-2.0 diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt index 937c9f2..f137195 100644 --- a/test-requirements-py3.txt +++ b/test-requirements-py3.txt @@ -16 +16 @@ testtools=0.9.36,!=1.2.0 -oslotest=1.2.0 # Apache-2.0 +oslotest=1.5.1,1.6.0 # Apache-2.0 @@ -25 +25 @@ sphinx=1.1.2,!=1.2.0,!=1.3b1,1.3 -oslosphinx=2.2.0 # Apache-2.0 +oslosphinx=2.5.0,2.6.0 # Apache-2.0 diff --git a/test-requirements.txt b/test-requirements.txt index 0b2a583..b6d3057 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -16 +16 @@ testtools=0.9.36,!=1.2.0 -oslotest=1.2.0 # Apache-2.0 +oslotest=1.5.1,1.6.0 # Apache-2.0 @@ -25 +25 @@ redis=2.10.0 -pyzmq=14.3.1 +pyzmq=14.3.1 # LGPL+BSD @@ -34 +34 @@ sphinx=1.1.2,!=1.2.0,!=1.3b1,1.3 -oslosphinx=2.2.0 # Apache-2.0 +oslosphinx=2.5.0,2.6.0 # Apache-2.0 __ 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] [puppet] openstacklib::db::sync proposal
On 06/08/2015 12:31 PM, Colleen Murphy wrote: On Sun, Jun 7, 2015 at 11:48 PM, Yanis Guenane yguen...@redhat.com mailto:yguen...@redhat.com wrote: On 06/03/2015 02:32 PM, Martin Mágr wrote: On 06/02/2015 07:05 PM, Mathieu Gagné wrote: On 2015-06-02 12:41 PM, Yanis Guenane wrote: The openstacklib::db::sync[2] is currently only a wrapper around an exec that does the actual db sync, this allow to make any modification to the exec into a single place. The main advantage IMO is that a contributor is provided with the same experience as it is not the case today across all modules. The amount of possible change to an exec resource is very limited. [1] I don't see a value in this change which outweighs the code churn and review load needed to put it in place. Unless we have real use cases or outrageously genius feature to add to it, I'm not in favor of this change. Furthermore, any change to the public interface of openstacklib::db::sync would require changes across all our modules anyway to benefit from this latest hypothetical feature. I think we are starting to nitpick over as little generic code we could possibly find to put in openstacklib. [1] https://docs.puppetlabs.com/references/latest/type.html#exec Wearing my consistency hat I must say I like this change. On the other hand I agree with Mathieu that delegating single resource from several modules to single module is necessary in this case. Regards, Martin Mathieu, Martin, thank you for replying. For the wrapper around exec usefulness I understand your concerns. On a note I was trying to follow the current use of openstacklib. If we look at openstacklib::db::postgresql[1] or openstackib::db::mysql[2] they are simple wrapper around puppet resources with no extra logic, but a common resource across all modules. The openstacklib::db::mysql resource is a wrapper around a couple of resources and contains logic around choosing an allowed hosts lists. I think it's worth to add the exec logic in this wrapper, which is Yanis's goal. We might want some consistency between our modules on this part, so I vote for solution #3 and agree on a common way to exec db sync. The openstacklib::db::postgresql is largely useless but makes the database interface consistent with mysql. Why is it useless? Colleen Also, to move forward on this topic I will submit to a vote one of the three propositions during our next meeting 1. Abandon this change 2. Move everything to X::db::sync, but just run the exec there, no openstacklib::db::sync 3. Move forward with current implementation Thanks again for the feedbacks, [1] https://github.com/stackforge/puppet-openstacklib/blob/master/manifests/db/postgresql.pp [2] https://github.com/stackforge/puppet-openstacklib/blob/master/manifests/db/mysql.pp -- Yanis Guenane __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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 -- Emilien Macchi signature.asc Description: OpenPGP digital 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-dev] [release][oslo] oslo.versionedobjects release 0.4.0 (liberty)
We are jubilant to announce the release of: oslo.versionedobjects 0.4.0: Oslo Versioned Objects library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.versionedobjects For more details, please see the git log history below and: http://launchpad.net/oslo.versionedobjects/+milestone/0.4.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.versionedobjects Changes in oslo.versionedobjects 0.3.0..0.4.0 - e61a3d3 Remove unnecessary openstack-common.conf dec261f Updated from global requirements ab13d2f fields: introduce BaseEnumField to allow subclassing df0cfdc fields: add a FlexibleBoolean field type Diffstat (except docs and test files) - openstack-common.conf | 7 --- oslo_versionedobjects/exception.py | 8 oslo_versionedobjects/fields.py| 56 -- requirements-py3.txt | 2 +- requirements.txt | 2 +- 6 files changed, 136 insertions(+), 13 deletions(-) Requirements updates diff --git a/requirements-py3.txt b/requirements-py3.txt index cc55d11..6e3d5ba 100644 --- a/requirements-py3.txt +++ b/requirements-py3.txt @@ -13 +13 @@ iso8601=0.1.9 -oslo.log=1.0.0 # Apache-2.0 +oslo.log=1.2.0 # Apache-2.0 diff --git a/requirements.txt b/requirements.txt index 30fda94..c613703 100644 --- a/requirements.txt +++ b/requirements.txt @@ -12 +12 @@ iso8601=0.1.9 -oslo.log=1.0.0 # Apache-2.0 +oslo.log=1.2.0 # Apache-2.0 __ 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] [release][oslo] oslo.config release 1.12.1 (liberty)
We are eager to announce the release of: oslo.config 1.12.1: Oslo Configuration API This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.config For more details, please see the git log history below and: http://launchpad.net/oslo.config/+milestone/1.12.1 Please report issues through launchpad: http://bugs.launchpad.net/oslo.config Changes in oslo.config 1.12.0..1.12.1 - 0c9113f Fix sorting issue in python 3 Diffstat (except docs and test files) - oslo_config/cfg.py| 2 +- 2 files changed, 15 insertions(+), 1 deletion(-) __ 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] [release][oslo] oslo.concurrency release 2.0.0 (liberty)
We are content to announce the release of: oslo.concurrency 2.0.0: Oslo Concurrency library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.concurrency For more details, please see the git log history below and: http://launchpad.net/oslo.concurrency/+milestone/2.0.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.concurrency Changes in oslo.concurrency 1.10.0..2.0.0 - b9e8f9f Remove oslo namespace package Diffstat (except docs and test files) - oslo/__init__.py | 13 - oslo/concurrency/__init__.py | 29 -- oslo/concurrency/fixture/__init__.py | 13 - setup.cfg| 5 - 10 files changed, 1361 deletions(-) __ 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] [javascript] Linters
Hey there, Gustavo- JSMin's a minifier, not a linter, yes? Unless I'm wrong, we're discussing the enforcement of code style rather than the concatenation step in our build, and thus jsmin's not really in the running. Once we _do_ talk about how we assemble javascript, I'm sure JSMin will have a strong following :) Michael On Mon, Jun 8, 2015 at 9:02 PM gustavo panizzo (gfa) g...@zumbi.com.ar wrote: On 2015-06-06 03:26, Michael Krotscheck wrote: Right now, there are several JS linters in use in OpenStack: JSHint, JSCS, and Eslint. I really would like to only use one of them, so that I can figure out how to sanely share the configuration between projects. Can all those who have a strong opinion please stand up and state their opinions? what about https://bitbucket.org/dcs/jsmin/ it's license is free -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: http://keybase.io/gfa __ 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] Liberty Priorties for Nova
On Tue, Jun 09, 2015 at 03:07:51PM +0100, Neil Jerram wrote: On 04/06/15 13:05, Neil Jerram wrote: Hi John, On 04/06/15 12:21, John Garbutt wrote: Hi, We had a great discussion at the summit around priorities: https://etherpad.openstack.org/p/YVR-nova-liberty-priorities I have made a stab at writing that up here, please to review if you are interested: https://review.openstack.org/#/c/187272/ Note we plan to keep focus on the reviews using the etherpad like we did in kilo: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking As you may have seen, I've collated libvirt/VIF type work at https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work. Where would you prefer any discussion about that to continue? Here on the ML, or in that review job? Hello again... So, just pinging again about the libvirt/VIF type work that I've collated at https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work. I'm keen if possible to have some kind of next step for discussing whether and how this work can be integrated into Nova's Liberty cycle. I wonder if it would help to present this work at a higher level - especially as it's really a grouping of three different kinds of work, and it may be that there is an elephant in the room of one of those kinds, which needs to be brought more into the open. Firstly there is a group of simple changes for new VIF types: TAP, macvtap, Infiniband SR-IOV; and removal of mlnx_direct. Changes of similar intent, scale and scope went in during Kilo, and I imagine that these could be reviewed and merged quite quickly, at any time from now on. It would be nice from my point of view to have that 'done', and perhaps from others' point of view too. Secondly there is the VIF plug script idea, and it's here that the elephant may be. I'm afraid that some of the interested people (including me) missed it, but I heard that the core team discussed this and expressed concern, in one of the Vancouver sessions, about 'not wanting Nova to become a pass-through API'. Since then, spec work has continued, but the only core input has come from Dan PB, who wasn't in that Vancouver session - so I'm worried that the Nova core team as a whole might not support this idea, and that the ongoing spec refinement might turn out to be rearranging the deck chairs on the Titanic. As you said, I wasn't there, so I don't know what the objections were, but I'm personally not supportive of adding any new VIF types until we have the VIF plugging script work done. This concept is critical to preventing the further explosion in the number of VIF types we need, and in allowing vendors to add new neutron mechanisms without always requiring a lock-step update to Nova. So from that POV I think the VIF script thing needs to be the #1 priority wrt VIF driver work in Nova/libvirt for Liberty. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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] [packaging] Adding packaging as an OpenStack project
On 06/09/2015 05:37 AM, Dirk Müller wrote: Hi Derek, 2015-06-09 0:34 GMT+02:00 Derek Higgins der...@redhat.com: This patch would result in 80 packaging repositories being pulled into gerrit. I personally would prefer to start with fewer but common packages between all RPM distros (is there more than Red Hat and SUSE ?) than starting the process with 80, but I wouldn't object to that. I agree, I would start with a limit set for the first pass. Especially since people haven't decided on the naming schema yet. o exactly what namespace/prefix to use in the naming, I've seen lots of opinions but I'm not clear if we have come to a decision o Should we use rdo in the packaging repo names and not rpm? I think this ultimatly depends whether the packaging can be shared between RDO and Suse or not. Well, we're (SUSE that is) are interested in sharing the packaging, and a non-RDO prefix would be preferred for the upstream coordination efforts. It is all a bit fuzzy for me right now as I'm not entirely sure our goals for packaging are necessarily the same (e.g. we have the tendency to include patches that have not been merged but are proposed upstream and are +1'ed already into our packages should there be a pressing need for us to do so (e.g. fixes an important platform bug), but maybe we can find enough common goals to make this a benificial effort for all of us. I agree too, rdo prefix is too specific in this case for a repo name. There are quite some details to sort out as our packaging is for historical and for various policy reasons that we need to stick to slightly different than the RDO packaging. I think going over those and see how we can merge them in a consolidated effort (or maintain two variants together) is the first step IMHO. Another important point for us is that we start with equal rights on the upstream collaboration (at least on the RPM side, I am fine with decoupling and not caring about the deb parts). I'm not overly optimistic that a single PTL would be able to cover both the DEB and RPM worlds, as I perceive them quite different in details. Greetings, Dirk __ 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] [release][oslo] oslotest release 1.7.0 (liberty)
We are content to announce the release of: oslotest 1.7.0: Oslo test framework This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslotest For more details, please see the git log history below and: http://launchpad.net/oslotest/+milestone/1.7.0 Please report issues through launchpad: http://bugs.launchpad.net/oslotest Changes in oslotest 1.6.0..1.7.0 5bd9b31 Updated from global requirements ff9b38e Fix argument handling in oslo_run_cross_tests 960e444 Add class to deal with clouds.yaml support 1c0863f Remove unneeded runtime pbr dep 5f2e635 Updated from global requirements f8a5a3c Advertise support for Python3.4 / Remove support for Python 3.3 a063f25 Do not sync run_cross_tests.sh 0782ab7 Remove unused discover dependency 9e0c8ad Remove six.moves call Diffstat (except docs and test files) - openstack-common.conf | 7 -- oslotest/__init__.py | 1 - oslotest/functional.py | 59 ++ oslotest/moxstubout.py | 2 +- requirements.txt | 3 +-- setup.cfg | 6 + tox.ini| 3 +-- 8 files changed, 83 insertions(+), 30 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 674130c..1486ede 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5,2 +4,0 @@ -pbr=0.6,!=0.7,1.0 -discover @@ -14,0 +13 @@ mox3=0.7.0 +os-client-config=1.2.0 __ 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] [puppet] openstacklib::db::sync proposal
On 2015-06-08 2:48 AM, Yanis Guenane wrote: If we look at openstacklib::db::postgresql[1] or openstackib::db::mysql[2] they are simple wrapper around puppet resources with no extra logic, but a common resource across all modules. I see a lot of resources, relationships and logic in openstackib::db::mysql. We can clearly see added value in that one. Also, to move forward on this topic I will submit to a vote one of the three propositions during our next meeting 1. Abandon this change 2. Move everything to X::db::sync, but just run the exec there, no openstacklib::db::sync 3. Move forward with current implementation I vote for 2 if we can make it happen in all modules and expose the same interface (parameters) for consistency. -- Mathieu __ 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] Liberty Priorties for Nova
On 04/06/15 13:05, Neil Jerram wrote: Hi John, On 04/06/15 12:21, John Garbutt wrote: Hi, We had a great discussion at the summit around priorities: https://etherpad.openstack.org/p/YVR-nova-liberty-priorities I have made a stab at writing that up here, please to review if you are interested: https://review.openstack.org/#/c/187272/ Note we plan to keep focus on the reviews using the etherpad like we did in kilo: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking As you may have seen, I've collated libvirt/VIF type work at https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work. Where would you prefer any discussion about that to continue? Here on the ML, or in that review job? Hello again... So, just pinging again about the libvirt/VIF type work that I've collated at https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work. I'm keen if possible to have some kind of next step for discussing whether and how this work can be integrated into Nova's Liberty cycle. I wonder if it would help to present this work at a higher level - especially as it's really a grouping of three different kinds of work, and it may be that there is an elephant in the room of one of those kinds, which needs to be brought more into the open. Firstly there is a group of simple changes for new VIF types: TAP, macvtap, Infiniband SR-IOV; and removal of mlnx_direct. Changes of similar intent, scale and scope went in during Kilo, and I imagine that these could be reviewed and merged quite quickly, at any time from now on. It would be nice from my point of view to have that 'done', and perhaps from others' point of view too. Secondly there is the VIF plug script idea, and it's here that the elephant may be. I'm afraid that some of the interested people (including me) missed it, but I heard that the core team discussed this and expressed concern, in one of the Vancouver sessions, about 'not wanting Nova to become a pass-through API'. Since then, spec work has continued, but the only core input has come from Dan PB, who wasn't in that Vancouver session - so I'm worried that the Nova core team as a whole might not support this idea, and that the ongoing spec refinement might turn out to be rearranging the deck chairs on the Titanic. Finally there is Brent's VIF model refactoring, where work is still in progress. So, it would be really great to get an indication of the core team's view of support for these things, of whether it's feasible for them to land during Liberty, and of any next steps that we need to work on, towards those ends. If appropriate, perhaps by adding these to the discussion agenda for the next IRC meeting? Many thanks, Neil __ 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] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
Sure, I’ve got the patch ready just waiting on a final decision re: governance. Brad On 9 Jun 2015, at 14:46, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: Adrian, I think you are on the road but perhaps you have access to email. Can you pull the trigger on your preferred governance approach? Brad will do the rest (creation of stackforge project, etc) From my perspective, the UI spec is ready to hit the repo and we shouldn’t block these folks good work because we can’t make a decision :). Given the broad interest from a lot of interested parties and no defined best practice in OpenStack for handling UI governance, I think a separate magnum-ui-core may make the most sense so the Magnum core team responsible for the infrastructure doesn’t balloon with a bunch of folks that don’t know much about Magnum in detail. If the ui dev team has slow reviews, which I doubt, we can add magnum-core to the magnum-ui-core team as a subteam in gerrit. I know this is a change in my previous stance, but I didn’t expect such broad interest. Brad, Once we get a decision from Adrian, can you submit a stackforge repo creation and link the review on this thread so interested parties can review appropriately? Regards, -steve From: Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 2:30 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Team, I have published a top level blueprint for a magnum-horizon-plugin: https://blueprints.launchpad.net/magnum/+spec/magnum-horizon-plugin My suggestion is that any contributor interested in contributing to this feature should subscribe to that blueprint, and record their intent to contribute in the Whiteboard of the BP. Furthermore, I suggest that any contributors who are a good fit for core reviewer duties for this effort subscribe to the blueprint and mark themselves as “Participation Essential” so I can get a clear picture of how to deal with grouping the related core reviewer team (or adding them to the current core group). I think that this effort would benefit from a spec submitted as a review using the following template: http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/liberty-template.rst Adapt it for magnum (I have not contributed a spec template of our own yet. TODO.) Contribute it here: http://git.openstack.org/cgit/openstack/magnum/tree/specs Thanks, Adrian On Jun 4, 2015, at 12:58 PM, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] [keystone][reseller] New way to get a project scoped token by name
On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox jamielen...@redhat.com
wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk
To: openstack-dev@lists.openstack.org
Sent: Saturday, 6 June, 2015 6:01:10 PM
Subject: Re: [openstack-dev] [keystone][reseller] New way to get a
project scoped token by name
On 06/06/2015 00:24, Adam Young wrote:
On 06/05/2015 01:15 PM, Henry Nash wrote:
I am sure I have missed something along the way, but can someone
explain to me why we need this at all. Project names are unique
within a domain, with the exception of the project that is acting as
its domain (i.e. they can only every be two names clashing in a
hierarchy at the domain level and below). So why isn’t specifying
“is_domain=True/False” sufficient in an auth scope along with the
project name?
The limitation of Project names are unique within a domain is
artificial and somethi8ng we should not be enforcing. Names should
only
be unique within parent project.
+++1
I said the exact same thing as Henry in the other thread that seems to be
on the same topic. You're correct the limitation of Project names are
unique within a domain is completely artificial, but it's a constraint
that allows us to maintain the auth systems we currently have and will not
harm the reseller model (because they would be creating new domains).
It's also a constraint that we can relax later when multitenancy is a bit
more established and someone has a real issue with the limitation - it's
not something we can ever claw back again if we allow some looking up
projects by name with delimiters.
I think for the time being it's an artificial constraint we should
maintain.
+1
This whole thing started by trying to distinguish a domain from a
project within that domain that both have the same name. We can special
case that, but it is not a great solution.
Henry
On 5 Jun 2015, at 18:02, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well
more to the point there should be a common one across OpenStack
installations to ensure we are providing a good and consistent (and
more to the point inter-operable) experience to our users. I'm
worried a custom defined delimiter (even at the domain level) is
going to make it difficult to consume this data outside of the
context of OpenStack (there are applications that are written to use
the APIs directly).
We have one already. We are working JSON, and so instead of project
name being a string, it can be an array.
Nothing else is backwards compatible. Nothing else will ensure we
don;t break exisiting deployments.
Moving forward, we should support DNS notation, but it has to be an
opt in
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy: {delim: ., domain.project.project2}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the
domain
entity? That seems like a good idea, although it does not
solve the
problem Morgan's mentioned that is the global hierarchy
delimiter.
There would be no global hierarchy delimiter. Each domain would
define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we
want a
domain, we
should always reference the namespace as we do today.
Basically, if we
ask for a project name we need to also provide it's
namespace (your
option #1). This clearly lines up with how we handle
projects in
domains
today.
I would, however, focus on how to represent the
namespace in a single
(usable) string. We've been delaying the work on this
for a while
since
Re: [openstack-dev] [Cinder] Getting `ValueError: Field `volume_id' cannot be None`
It should be a field, e.g. admin_metadata, in the snapshot object under
object/snapshot.py. Look at 'metadata' field as an example of how to
accomplish this.
Thang
On Tue, Jun 9, 2015 at 11:06 AM, Deepak Shetty dpkshe...@gmail.com wrote:
Thangp,
I have a related Question wrt your comment in
https://review.openstack.org/#/c/172808/6/cinder/api/contrib/snapshot_actions.py
Do i need to add support for snapshot_admin_metadata table in
object/snapshot.py or I need to create
a new object since its a new table, I am not clear on this, can you let me
know pls ?
ALternatively I am fine if you want to collaborate on my patch and add
snapshot_admin_metadata object support too ?
Let me know pls
thanx,
deepak
On Tue, Jun 9, 2015 at 12:12 PM, Deepak Shetty dpkshe...@gmail.com
wrote:
Thang,
Thanks! Its still not clear to me why my method doesn't work. FWIW, i
did try db.snapshot_get = mock.Mock(...) before and when that didn't work,
i was just trying out
with remotefs.db.snapshot_get with the assumption that maybe some scope
issue is there hence I should try using the complete path right from
module, but that didn't work either and i guess its still not clear why
a mock in one test module affects another.
Given that mock.patch is working as evident from your patch, i will
continue to use it.
Thanks for helping out.
On Thu, Jun 4, 2015 at 9:21 PM, Thang Pham thang.g.p...@gmail.com
wrote:
The problem is in your test case. There is no such methods as
remotefs.db.snapshot_get or remotefs.db.snapshot_admin_metadata_get.
You need to use with mock.patch('cinder.db.snapshot_get') as snapshot_get,
mock.patch('cinder.db.snapshot_admin_metadata_get')
as snapshot_admin_metadata_get. These incorrect calls somehow created a
side effect in the other test cases. I updated you patch with what is
correct, so you should follow it for you other tests. Your test case needs
a lot more work, I just edited it to just have it pass the unit tests.
Thang
On Thu, Jun 4, 2015 at 4:36 AM, Deepak Shetty dpkshe...@gmail.com
wrote:
I was able to narrow down to the scenario where it fails only when i do:
./run_tests.sh -N cinder.tests.unit.test_remotefs
cinder.tests.unit.test_volume.VolumeTestCase
and fails with:
{0}
cinder.tests.unit.test_volume.VolumeTestCase.test_can_delete_errored_snapshot
[0.507361s] ... FAILED
Captured traceback:
~~~
Traceback (most recent call last):
File cinder/tests/unit/test_volume.py, line 3029, in
test_can_delete_errored_snapshot
snapshot_obj = objects.Snapshot.get_by_id(self.context,
snapshot_id)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 169,
in wrapper
result = fn(cls, context, *args, **kwargs)
File cinder/objects/snapshot.py, line 130, in get_by_id
expected_attrs=['metadata'])
File cinder/objects/snapshot.py, line 112, in _from_db_object
snapshot[name] = value
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 691,
in __setitem__
setattr(self, name, value)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 70,
in setter
field_value = field.coerce(self, name, value)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/fields.py, line
183, in coerce
return self._null(obj, attr)
File
/usr/lib/python2.7/site-packages/oslo_versionedobjects/fields.py, line
161, in _null
raise ValueError(_(Field `%s' cannot be None) % attr)
ValueError: Field `volume_id' cannot be None
Both the testsuites run fine when i run them individually, as in the
below is success:
./run_tests.sh -N cinder.tests.unit.test_remotefs - no errors
./run_tests.sh -N cinder.tests.unit.test_volume.VolumeTestCase - no
errors
So i modified my patch @ https://review.openstack.org/#/c/172808/
(Patch set 6) and
removed all testcase i added in test_remotefs.py except one, so that we
have lesser code to debug/deal with!
See
https://review.openstack.org/#/c/172808/6/cinder/tests/unit/test_remotefs.py
Now when i disable test_create_snapshot_online_success then running
both the suites work,
but when i enable test_create_snapshot_online_success then it fails as
above.
I am unable to figure whats the connection between
test_create_snapshot_online_success
in test_remotefs.py
and VolumeTestCase.test_can_delete_errored_snapshot in test_volume.py
failure
Can someone help here ?
thanx,
deepak
On Thu, Jun 4, 2015 at 1:37 PM, Deepak Shetty dpkshe...@gmail.com
wrote:
Hi Thang,
Since you are working on Snapshot Objects, any idea on why the
testcase when run all by itself, works, but when run as part of the
overall
suite, fails ?
This seems to be related to the Snapshot Objects, hence Ccing you.
On Wed, Jun 3, 2015 at 9:54 PM, Deepak Shetty dpkshe...@gmail.com
wrote:
Hi All,
I am hitting a strange issue when
Re: [openstack-dev] Barbican : Retrieval of the secret in text/plain format generated from Barbican order resource
Hi Douglas ,
It would be great if you could respond to the email with the explanation
provided in yesterday's IRC meeting so that I can share it with my team.
Thanks and Regards,
Asha Seshagiri
On Mon, Jun 8, 2015 at 2:13 PM, Asha Seshagiri asha.seshag...@gmail.com
wrote:
Thanks Nate for your response.
I would need Barbican to generate the key in plain/text format which is
the human readable form so that I can use that key in Standard Crytp graphy
libraries in python which takes key as the argument.
Yeah , text/plain format means the bytes are in base64 format.
Thanks and Regards,
Asha Seshgiri
On Mon, Jun 8, 2015 at 8:37 AM, Nathan Reller nathan.s.rel...@gmail.com
wrote:
Asha,
When you say you want your key in ASCII does that also mean putting
the bytes in hex or base64 format? Isn't ASCII only 7 bits?
-Nate
On Mon, Jun 8, 2015 at 1:17 AM, Asha Seshagiri asha.seshag...@gmail.com
wrote:
Thanks John for your response.
I am aware that application/octet-stream works for the retrieval of
secret .
We are utilizing the key generated from Barbican in our AES encryption
algorithm . Hence we wanted the response in text/plain format from
Barbican
since AES encryption algorithm would need the key of ASCII format which
should be either 16,24 or 32 bytes.
The AES encyption algorithms would not accept the binary format and
even if
binary is converted into ascii , encoding is failing for few of the
keys
because some characters exceeeds the range of ASCII and for some keys
after
encoding length exceeds 32 bytes which is the maximum length for doing
AES
encryption.
Would like to know the reason behind Barbican not supporting the
retrieval
of the secret in text/plain format generated from the order resource in
plain/text format.
Thanks and Regards,
Asha Seshagiri
On Sun, Jun 7, 2015 at 11:43 PM, John Wood john.w...@rackspace.com
wrote:
Hello Asha,
The AES type key should require an application/octet-stream Accept
header
to retrieve the secret as it is a binary type. Please replace
‘text/plain’
with ‘application/octet-stream’ in your curl calls below.
Thanks,
John
From: Asha Seshagiri asha.seshag...@gmail.com
Date: Friday, June 5, 2015 at 2:42 PM
To: openstack-dev openstack-dev@lists.openstack.org
Cc: Douglas Mendizabal douglas.mendiza...@rackspace.com, John Wood
john.w...@rackspace.com, Reller, Nathan S.
nathan.rel...@jhuapl.edu,
Adam Harwell adam.harw...@rackspace.com, Paul Kehrer
paul.keh...@rackspace.com
Subject: Re: Barbican : Retrieval of the secret in text/plain format
generated from Barbican order resource
Hi All ,
I am currently working on use cases for database and file
Encryption.It is
really important for us to know since my Encryption use case would be
using
the key generated by Barbican through order resource as the key.
The encyption algorithms would not accept the binary format and even if
converted into ascii , encoding is failing for few of the keys because
some
characters exceeeds the range of ASCII and for some key after encoding
length exceeds 32 bytes which is the maximum length for doing AES
encryption.
It would be great if someone could respond to the query ,since it
would
block my further investigations on Encryption usecases using Babrican
Thanks and Regards,
Asha Seshagiri
On Wed, Jun 3, 2015 at 3:51 PM, Asha Seshagiri
asha.seshag...@gmail.com
wrote:
Hi All,
Unable to retrieve the secret in text/plain format generated from
Barbican order resource
Please find the curl command and responses for
Order creation with payload content type as text/plain :
[root@barbican-automation ~]# curl -X POST -H
'content-type:application/json' -H
X-Auth-Token:9b211b06669249bb89665df068828ee8 \
-d '{type : key, meta: {name: secretname2,algorithm:
aes,
bit_length:256, mode: cbc, payload_content_type:
text/plain}}'
-k https://169.53.235.102:9311/v1/orders
{order_ref:
https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680
}
Retrieval of the order by ORDER ID in order to get to know the secret
generated by Barbican
[root@barbican-automation ~]# curl -H 'Accept: application/json' -H
X-Auth-Token:9b211b06669249bb89665df068828ee8 \
-k
https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680
{status: ACTIVE, sub_status: Unknown, updated:
2015-06-03T19:08:13, created: 2015-06-03T19:08:12, order_ref:
https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680
,
secret_ref:
https://169.53.235.102:9311/v1/secrets/5c25525d-a162-4b0b-9954-90c4ce426c4e
,
creator_id: cedd848a8a9e410196793c601c03b99a, meta: {name:
secretname2, algorithm: aes, payload_content_type:
text/plain,
mode: cbc, bit_length: 256, expiration: null},
sub_status_message:
Unknown, type: key}[root@barbican-automation ~]#
Retrieval of the secret
Re: [openstack-dev] [Fuel][Oslo][RabbitMQ][Shovel] Deprecate mirrored queues from HA AMQP cluster scenario
On 9 June 2015 at 10:26:27, Michael Klishin (mklis...@pivotal.io) wrote: I will push for introducing the most basic timeout support in ctl in the next bug fix release. Some (highly conservative, for the sake of backwards compatibility) improvements are already merged and will be in 3.5.4 : https://github.com/rabbitmq/rabbitmq-server/pull/181 -- MK Staff Software Engineer, Pivotal/RabbitMQ __ 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] Hyper-V meeting today
We don't seem to have quorum today to have a meeting. Pushing until next week. p Peter J. Pouliot CISSP Microsoft Enterprise Cloud Solutions C:\OpenStack New England Research Development Center 1 Memorial Drive Cambridge, MA 02142 P: 1.(857).4536436 E: ppoul...@microsoft.commailto:ppoul...@microsoft.com __ 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] [all] starting oslo releases without namespace packages
Today we started releasing versions of some of the Oslo libraries without the oslo namespace package. This represents a backwards-incompatible API change, so we have raised the major version number on those libraries where appropriate (oslo.vmware is not yet 1.0, so we didn't raise the major version there). There are several more libraries to be released in the coming weeks, as part of the remove-namespace-packages blueprint. We expect to have all of them done by the end of liberty, and I am submitting changes to the global requirements list to raise the minimum supported versions of each lib as versions without the package are tagged. Doug __ 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] [javascript] Linters
Well, it looks like everyone has disqualified jslint and jshint, so let's just make a decision there and remove them from the running. Unless I hear a compelling reason to use something that has the infamous do no evil license in it, let's dump it. The John Papa styles seem sane, and though I disagree with them, I'd be ok using them. Putting everything in a closure is an old standard that has usually just annoyed me, since it's one of those things about javascript that _shouldn't_ have to be explicit, but no language is perfect ;). The existing eslint stylesheets that exist in StoryBoard and others were written with PEP8 in mind, in order to facilitate readability between our languages, however I am also a strong believer in treating JavaScript on equal terms with other languages. Also, John papa seems to have more opinions about angular apps than javascript in general, so I propose this rule for OpenStack going forward: 1- If the John Papa rules have an opinion, use that. 2- Otherwise, use pep8 (where applicable). 3- Otherwise, check to see if there's a thing in hacking. 4- If it's in none of those, we'll address it on a case by case basis. The main reasons for this is that I simply do not want to have an argument about spaces vs. tabs. The arguments about PEP8 have already been had, and the benefits of a language-wide enforced style are simple: We can argue about more important things! :). Let's assume a week of commentary on the above. As for how this is synchronized, a brief discussion in the infra channel proposed that we put global javascript requirements in the global-requirements repo, and then update the update.py script in that repo to also handle bower.json and package.json. Then, if we build an eslint/jscs plugin similar to our hacking rules, we can just update that when we want to modify the linting rules. Any objections? With regards to JSCS vs. Eslint, I feel that we actually have to use both to decide which is better: Once we set up the rules side by side and try to apply them against a project, a clear winner will emerge. Does anyone want to volunteer to put together a spreadsheet of all the rules from John Papa and pep8 that we'd like to enforce, and the appropriate rule in eslint and/or jscs that applies? Michael On Mon, Jun 8, 2015 at 9:57 PM Tripp, Travis S travis.tr...@hp.com wrote: We¹ve adopted the John Papa style guide for Angular in horizon [0]. On cursory inspection ES lint seems to have an angular specific plugin [1] that could be very useful to us, but we¹d need to evaluate it in depth. It looks like there was some discussion on the style guide on this not too long ago [2]. The jscs rules we have [3] are very generic code formatting type rules that are helpful, but don't really provide any angular specific help. Here are the jshint rules [4]. It would be quite nice to put all this goodness across tools into a single tool configuration if possible. [0] http://docs.openstack.org/developer/horizon/contributing.html#john-papa-sty le-guide http://docs.openstack.org/developer/horizon/contributing.html#john-papa-style-guide [1] https://www.npmjs.com/package/eslint-plugin-angular [2] https://github.com/johnpapa/angular-styleguide/issues/194 [3] https://github.com/openstack/horizon/blob/master/.jscsrc [4] https://github.com/openstack/horizon/blob/master/.jshintrc On 6/8/15, 9:59 PM, gustavo panizzo (gfa) g...@zumbi.com.ar wrote: On 2015-06-06 03:26, Michael Krotscheck wrote: Right now, there are several JS linters in use in OpenStack: JSHint, JSCS, and Eslint. I really would like to only use one of them, so that I can figure out how to sanely share the configuration between projects. Can all those who have a strong opinion please stand up and state their opinions? what about https://bitbucket.org/dcs/jsmin/ it's license is free -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: http://keybase.io/gfa __ 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] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC
Actually I misread the time, 1700 UTC is 6pm Irish time which is not as good for me. So -1 On 09/06/15 09:30, Paul Bourke wrote: +1 On 08/06/15 18:37, Smigiel, Dariusz wrote: Folks, Several people have messaged me from EMEA timezones that 1600UTC fits right into the middle of their family life (ferrying kids from school and what-not) and 1700UTC while not perfect, would be a better fit time-wise. For all people that intend to attend the 1600 UTC, could I get your feedback on this thread if a change of the 1600UTC timeslot to 1700UTC would be acceptable? If it wouldn't be acceptable, please chime in as well. Thanks -steve +1 It suits me. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] oslo releasing is noisy...
Victor Stinner wrote: Le 09/06/2015 17:50, Jordan Pittier a écrit : Hi, This has already been discussed here: http://lists.openstack.org/pipermail/openstack-dev/2015-March/059020.html You can always create a filter to match these emails. Well, I'm doing the opposite: I want to read (all) Oslo emails, so I move them into a dedicated folder in my mail box ;-) I like these release emails to see what changes, especially because Oslo releases break things sometimes ;-) It's better to stay tuned. We are currently exploring the option to repurpose the openstack-announce ML to be the extensive record of release announcements. It's part of a larger plan to streamline library releases, about which Doug should start a discussion pretty soon now. If we did that, we'd likely post to openstack-announce with Reply-To set to openstack-dev (so that any discussion on the recent release would happen on the open list). -- Thierry Carrez (ttx) __ 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] [glance] How to deal with aborted image read?
On 06/08/2015 06:26 PM, Robert Collins wrote: On 9 June 2015 at 07:53, Chris Friesen chris.frie...@windriver.com wrote: From what I understand, the iterator (in the glance-api process) normally breaks out of the while loop once the whole file has been read and the read() call returns an empty string. It's not clear to me how an error in the nova process (which causes it to stop reading the file from glance-api) will cause glance-api to break out of the while loop in ChunkedFile.__iter__(). AIUI the conclusion of our IRC investigation was: - with caching middleware, the fd is freed, just after ~4m. - without caching middleware, the fd is freed after ~90s. Correct. I went back and tried it out in a hardware lab and those are the results I got. Sorry for the noise (though it'd be nice to get rid of the 4-minute delay). I did a bit more digging and we've apparently got another similar issue reported where taking a snapshot fails because the filesystem fills up and the space never gets reclaimed even though the snapshot failed. I'll make sure I can reproduce that one before going further. Chris __ 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] [horizon][i18n] Ordering of PO files
Ok, thats good to hear! Thanks Akihiro for the clarification.Andreas, I believe we can rewire the --makemessages command to use Babel, so script update will not be required.-Andreas Jaeger a...@suse.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Andreas Jaeger a...@suse.comDate: 06/09/2015 12:03AMSubject: Re: [openstack-dev] [horizon][i18n] Ordering of PO filesOn 06/09/2015 01:28 AM, Thai Q Tran wrote: Hi folks, In the midst of shifting to angular, we are making use of babel for extracting messages. This would then allow us to write a custom extractor for angular templates. Here's the patch that compare PO files: https://review.openstack.org/#/c/189502/ It looks worse than reality, if you compare the django vs babel makemessages, they are nearly identical, only the ordering is different. Which leads me to my next point. If the ordering of the translatable strings are not the same, how does that affect translation (if at all)?It doesn't.Our tools always sort the entries, we call for all files:msgattrib --translated --no-location --sort-output "$i" \ --output="${i}.tmp"Please use the same commands for generation as our tools. For horizon see http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/propose_translation_update_horizon.shAndreas-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [release][openstackclient] cliff release 1.13.0 (liberty)
We are happy to announce the release of: cliff 1.13.0: Command Line Interface Formulation Framework This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/cliff For more details, please see the git log history below and: https://launchpad.net/python-cliff/+milestone/1.13.0 Please report issues through launchpad: https://bugs.launchpad.net/python-cliff Changes in cliff 1.12.0..1.13.0 --- 8a4a93f Fix object has no attribute debug error c904cd0 Add some docs for list value formatter 24120da Add value format for list command bacb4c6 Updated from global requirements ec7549c Remove run_cross_tests.sh f8549ff fix author contact details efdbc03 Print help on help command 6d29200 Add documentation for the value formatter a84421e Sort the fuzzy matches b6efad3 Defer interactive import Diffstat (except docs and test files) - .gitignore | 4 +++ cliff/app.py | 10 -- cliff/formatters/value.py| 10 +- cliff/help.py| 5 +-- requirements.txt | 2 +- setup.cfg| 5 +-- 11 files changed, 100 insertions(+), 97 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 0bc229b..0a48fca 100644 --- a/requirements.txt +++ b/requirements.txt @@ -4 +4 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 __ 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] [puppet] Weekly meeting #37
Our meeting minutes this week: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-06-09-15.00.html Thanks everyone, -- Emilien Macchi signature.asc Description: OpenPGP digital 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
Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x
On 6/9/15 9:26 AM, Thomas Goirand wrote: Hi, The python-sqlalchemy package has been uploaded to Debian Experimental, and is about to be uploaded to Debian Unstable. So I wonder what's the state of the project regarding upgrading SQLA. Maybe Mike can tell what kind of issue we may run into? How much work will it be to switch to SQLA 1.0.x for Liberty? Is it possible to be compatible with both 9.x and 1.x (which would be the best way forward)? The short answer is that there are no supported use cases that have been intentionally changed in any backwards incompatible way in 1.0 and all Openstack code should be able to accommodate from 0.9.x - 1.0.x without any change. I run SQLAlchemy's master against a small subset of Openstack tests continuously, including Nova DB API, Keystone, all of oslo.db and Neutron's migration tests, and there was nothing that needed changing as we went along. I've also run devstack against SQLAlchemy 1.0 without problems though I don't have a lot of openstack-user-fu so I didn't stress test it too much at that level. It's my expectation that nothing in Openstack should have to change to work with SQLAlchemy 1.0 - the kinds of things that change tend to be subtle things related to odd use cases and newer features, usually along the lines of applications that may have been relying upon some behavior that was undefined, that then changes it's behavior in some way. An example is that we had a user who was running a query of the form session.query(SomeObject).with_parent(SomeParent(id=None)), e.g. trying to find objects that *didn't* have a parent by using a transient Parent with id=None - totally unexpected way of doing that, and it wasn't even working for that user as it came up with an = NULL comparison that isn't even right, *but* when SQLA 1.0 came around it started leaking an internal symbol into the query, and *then* it became noticeable. That's the kind of thing that breaks with new SQLAlchemy versions these days. We had a lot of those this time around, and the vast majority of them were logged as regressions which were fixed and added to testing. You can see those by browsing versions 1.0.1 - 1.0.5 at http://docs.sqlalchemy.org/en/rel_1_0/changelog/changelog_10.html. We never intentionally make *any* backwards incompatible change in just one major version without warnings being emitted in the previous version, and the warnings usually involve urging the user to set a flag to use the old way if they're going to upgrade; that is, we at least always try to add flags to keep an old behavior in place if at all possible. I've not seen anything in Openstack that would be sensitive to this kind of issue for 1.0. So for Openstack, we would mostly worry about code that is doing things oddly in some unexpected way, however all the Openstack code I've seen tends to be very ORM centric and uses the ORM very conservatively so I don't anticipate any problems. I would note that some silently-/ quasi- failing use cases for query.update() and query.delete() now raise exceptions in 1.0. They both emit warnings in 0.9 but I just checked and apparently one of these warnings is only in the as-yet unreleased 0.9.10. I've just added an extra migration note for one of these which appeared to be missing in the migration document (as of this writing it should be up on RTD within an hour). That said, the document which tries to capture everything that might be surprising is at http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html. Cheers, Thomas Goirand (zigo) __ 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] [nova] FreeBSD host support, round 2
Hi, Few months ago I've started a discussion on FreeBSD host support for OpenStack. [1] At a result of discussion it was figured out that there are a number of limitations, mainly on the BHyVe (the FreeBSD hypervisor) side, that make the effort not feasible. However, some things changed since then. Specifically, FreeBSD's got Xen dom0 support. [2] In context of OpenStack deployment that has a number of benefits over bhyve. Specifically: * The stack is more mature and feature-rich * The toolstack is here already: libxl is available through the FreeBSD ports tree, libvirt/libxl works there with minimal modifications (already available in the git master) * OpenStack libvirt/libxl driver is already here I was able to setup a proof-of-concept environment on FreeBSD that required quite a small amount of modifications required in OpenStack: * Glance and Keystone didn't require any changes * Nove required some minor modifications mainly in the linux_net.py area The summary of Nova modifications: * I had to implement FreeBSD version of linux_net.LinuxNetInterfaceDriver. It currently doesn't support vlans though. https://github.com/novel/bsdstack/blob/master/bsdstack/nova/network/freebsd_net.py I keep it as an external package and configure Nova to use it through linuxnet_interface_driver config option in nova.conf * I had to create a stub for the IptablesManager class. I also had to add a config option to be able to override class for that in a way similar to interface driver. * I had to fix a minor interface incapability for NullL3 stub, that's already in the Nova tree: https://review.openstack.org/#/c/189001/ * I added a hack to use 'phy' driver in domain's xml for disks because for some reason driver='qemu' results in guests not able to access disk devices (tried both FreeBSD and Linux guests). Need to investigate * Dropped some LinuxBridgeInterfaceDriver hardcodes in virt.libvirt.vif. Here's a quick overview of my changes: https://github.com/novel/nova/compare/stable/kilo...novel:stable/kilo_freebsd?expand=1 With this changes I was able to get things working, i.e. VM starting, obtaining IP addresses (with nova-network configured with FlatDHCP) etc. Having that said I'm wondering if community is interested in integrating FreeBSD support through libvirt/libxl into mainline? Obviously, the changes I provided are shortcuts and the appropriate specs should be create with proposals of proper designs, not quick hacks like that. The biggest part of the unportable code, just like it was in bhyve case, is still linux_net.py, so probably it makes sense to revive the old spec: https://review.openstack.org/#/c/127827/ TBH, IMHO linux_net.py could have a refactor regardless of FreeBSD support. It's approx. 2000 lines long, contains a lot of stuff like dnsmasq handling code, interface handing code and firewall management that could have their own place. Feedback is appreciated, Thanks 1: http://lists.openstack.org/pipermail/openstack-dev/2014-October/048721.html 2: http://wiki.xen.org/wiki/FreeBSD_Dom0 Roman Bogorodskiy pgpu0F_6bRBdH.pgp Description: 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
Re: [openstack-dev] [nova] FreeBSD host support, round 2
On Tue, Jun 09, 2015 at 07:52:39PM +0300, Roman Bogorodskiy wrote: Hi, Few months ago I've started a discussion on FreeBSD host support for OpenStack. [1] At a result of discussion it was figured out that there are a number of limitations, mainly on the BHyVe (the FreeBSD hypervisor) side, that make the effort not feasible. Do you still intend to add the missing features to BHyve to let it be supported in Nova eventually too ? However, some things changed since then. Specifically, FreeBSD's got Xen dom0 support. [2] In context of OpenStack deployment that has a number of benefits over bhyve. Specifically: * The stack is more mature and feature-rich * The toolstack is here already: libxl is available through the FreeBSD ports tree, libvirt/libxl works there with minimal modifications (already available in the git master) * OpenStack libvirt/libxl driver is already here I was able to setup a proof-of-concept environment on FreeBSD that required quite a small amount of modifications required in OpenStack: * Glance and Keystone didn't require any changes * Nove required some minor modifications mainly in the linux_net.py area The summary of Nova modifications: * I had to implement FreeBSD version of linux_net.LinuxNetInterfaceDriver. It currently doesn't support vlans though. https://github.com/novel/bsdstack/blob/master/bsdstack/nova/network/freebsd_net.py I keep it as an external package and configure Nova to use it through linuxnet_interface_driver config option in nova.conf * I had to create a stub for the IptablesManager class. I also had to add a config option to be able to override class for that in a way similar to interface driver. * I had to fix a minor interface incapability for NullL3 stub, that's already in the Nova tree: https://review.openstack.org/#/c/189001/ * I added a hack to use 'phy' driver in domain's xml for disks because for some reason driver='qemu' results in guests not able to access disk devices (tried both FreeBSD and Linux guests). Need to investigate * Dropped some LinuxBridgeInterfaceDriver hardcodes in virt.libvirt.vif. Here's a quick overview of my changes: https://github.com/novel/nova/compare/stable/kilo...novel:stable/kilo_freebsd?expand=1 With this changes I was able to get things working, i.e. VM starting, obtaining IP addresses (with nova-network configured with FlatDHCP) etc. Having that said I'm wondering if community is interested in integrating FreeBSD support through libvirt/libxl into mainline? Obviously, the changes I provided are shortcuts and the appropriate specs should be create with proposals of proper designs, not quick hacks like that. I'd be happy to see FreeBSD support for any of the libvirt hypervisors added to Nova. As you point out, the changes to the libvirt code are going to be pretty minimal for libxl, so there's not going to be any appreciable ongoing maint burden for this. So I see no serious reason to reject the changes to Nova libvirt driver code for libxl+FreeBSD. The fun bit will be the changes to non-libvirt code in nova... The biggest part of the unportable code, just like it was in bhyve case, is still linux_net.py, so probably it makes sense to revive the old spec: https://review.openstack.org/#/c/127827/ TBH, IMHO linux_net.py could have a refactor regardless of FreeBSD support. It's approx. 2000 lines long, contains a lot of stuff like dnsmasq handling code, interface handing code and firewall management that could have their own place. Yes, that network setup code is really awful and I'd love to see it refactored regardless of FreeBSD support. With my crystal ball, probably the main question wrt any kind of FreeBSD support will be that of 3rd party CI testing. I don't know whether there is any company backing your work who has resources to provide a CI system, or whether FreeBSD project can manage it independently ? The refactoring of the linux_net.py code could be done even without CI support of course - that would only block the second part where you actually add a FreeBSD implementation Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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] [Keystone] Midcycle
Keystone Liberty Midcycle Meetup Time and Location When: July 15-17 (Wed-Fri) Where: Boston University, Boston, MA, USA Keystone Midcycle Wiki page: https://wiki.openstack.org/wiki/Sprints/KeystoneLibertySprint Please sign up if you are attending __ 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] [Neutron] API Extensions - Namespace URLs
I believe XML support got removed from the API last cycle. From: Jay Pipes jaypi...@gmail.com Sent: Tuesday, June 9, 2015 1:08 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs On 06/08/2015 05:10 PM, Sean M. Collins wrote: Hi, Within each API extension in the neutron tree, there is a method: def get_namespace(cls): Which returns a string, containing a URL. snip I believe that they all 404. A dumb question to start, then progressively smarter questions: * What is the purpose of the URLs? They are the sad detritus left from XML support. * Should the URL point to documentation? Perhaps. * What shall we do about the actual URLs 404'ing? Honestly, I'd prefer the namespaces just be removed, but I'm not sure what Neutron's position is about XML and the REST API... Best, -jay __ 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] [all] Switching to SQLAlchemy 1.0.x
On 6/9/15 1:08 PM, Mike Bayer wrote: So for Openstack, we would mostly worry about code that is doing things oddly in some unexpected way, however all the Openstack code I've seen tends to be very ORM centric and uses the ORM very conservatively so I don't anticipate any problems. I would note that some silently-/ quasi- failing use cases for query.update() and query.delete() now raise exceptions in 1.0. They both emit warnings in 0.9 but I just checked and apparently one of these warnings is only in the as-yet unreleased 0.9.10. I've just added an extra migration note for one of these which appeared to be missing in the migration document (as of this writing it should be up on RTD within an hour). That said, the document which tries to capture everything that might be surprising is at http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html. here are those: http://sqlalchemy.readthedocs.org/en/rel_1_0/changelog/migration_10.html#query-update-query-delete-raises-if-used-with-join-select-from-from-self http://sqlalchemy.readthedocs.org/en/rel_1_0/changelog/migration_10.html#query-update-with-synchronize-session-evaluate-raises-on-multi-table-update Cheers, Thomas Goirand (zigo) __ 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
[openstack-dev] [kolla] Scheduling for a mid-cycle - doodle poll inside
This is an open invitation to Operators that have an interest in contributing to the Kolla design around deployment to participate in a 2 day design focused midcycle summit. The hours will run from 10:00 AM to 5:00 PM PST and the location will be in San Jose, CA in the US. The two days will be scheduled together. Please record all days you can attend so I can schedule the best possible coverage for the most individuals. The doodle poll is located here: http://doodle.com/su62amktdrp5mrez I’ll keep the poll open for a one week period until June 17th. Regards -steve __ 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] [infra] how to trigger a set of jenkins jobs
On 06/09/2015 05:33 AM, Gareth wrote: Hi infra team, The origin concept of jenkins is one trigger one job. For example, the job neutron-unit-test-py27 could respond a new change set from neutron upstream. But the truth is that a gerrit event trigger a set of jenkins jobs: py27-unittest, pep8-check, and many dsvm jobs... How can I configure my jenkins like this? __ 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 We use a tool called Zuul written expressly for our needs which has a concept of pipelines. The status of the patch in Gerrit (Workflow 0, Workflow +1, merged) gives Zuul the information it needs to put a patchset in a given pipeline based on a new event. A repo will have a cluster of jobs set based on pipeline. Here is the zuul configuration file for the openstack/keystone repo: http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml#n1832 There are templates which are common across many repos, then specific jobs for the check pipeline, gate pipeline, post pipeline (which means post merge) and the experimental pipeline (which we created as a way of graduating new jobs). Here would be a good place to begin reading about zuul: http://docs.openstack.org/infra/system-config/zuul.html Thanks, Anita. __ 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] [all] Switching to SQLAlchemy 1.0.x
On Tue, Jun 9, 2015 at 8:08 PM, Mike Bayer mba...@redhat.com wrote: On 6/9/15 9:26 AM, Thomas Goirand wrote: Hi, The python-sqlalchemy package has been uploaded to Debian Experimental, and is about to be uploaded to Debian Unstable. So I wonder what's the state of the project regarding upgrading SQLA. Maybe Mike can tell what kind of issue we may run into? How much work will it be to switch to SQLA 1.0.x for Liberty? Is it possible to be compatible with both 9.x and 1.x (which would be the best way forward)? The short answer is that there are no supported use cases that have been intentionally changed in any backwards incompatible way in 1.0 and all Openstack code should be able to accommodate from 0.9.x - 1.0.x without any change. Just posted a patch to test this out: https://review.openstack.org/189847 I run SQLAlchemy's master against a small subset of Openstack tests continuously, including Nova DB API, Keystone, all of oslo.db and Neutron's migration tests, and there was nothing that needed changing as we went along. I've also run devstack against SQLAlchemy 1.0 without problems though I don't have a lot of openstack-user-fu so I didn't stress test it too much at that level. It's my expectation that nothing in Openstack should have to change to work with SQLAlchemy 1.0 - the kinds of things that change tend to be subtle things related to odd use cases and newer features, usually along the lines of applications that may have been relying upon some behavior that was undefined, that then changes it's behavior in some way. An example is that we had a user who was running a query of the form session.query(SomeObject).with_parent(SomeParent(id=None)), e.g. trying to find objects that *didn't* have a parent by using a transient Parent with id=None - totally unexpected way of doing that, and it wasn't even working for that user as it came up with an = NULL comparison that isn't even right, *but* when SQLA 1.0 came around it started leaking an internal symbol into the query, and *then* it became noticeable. That's the kind of thing that breaks with new SQLAlchemy versions these days. We had a lot of those this time around, and the vast majority of them were logged as regressions which were fixed and added to testing. You can see those by browsing versions 1.0.1 - 1.0.5 at http://docs.sqlalchemy.org/en/rel_1_0/changelog/changelog_10.html. We never intentionally make *any* backwards incompatible change in just one major version without warnings being emitted in the previous version, and the warnings usually involve urging the user to set a flag to use the old way if they're going to upgrade; that is, we at least always try to add flags to keep an old behavior in place if at all possible. I've not seen anything in Openstack that would be sensitive to this kind of issue for 1.0. So for Openstack, we would mostly worry about code that is doing things oddly in some unexpected way, however all the Openstack code I've seen tends to be very ORM centric and uses the ORM very conservatively so I don't anticipate any problems. I would note that some silently-/ quasi- failing use cases for query.update() and query.delete() now raise exceptions in 1.0. They both emit warnings in 0.9 but I just checked and apparently one of these warnings is only in the as-yet unreleased 0.9.10. I've just added an extra migration note for one of these which appeared to be missing in the migration document (as of this writing it should be up on RTD within an hour). That said, the document which tries to capture everything that might be surprising is at http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html. Cheers, Thomas Goirand (zigo) __ 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] [Openstack-operators] [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries in addn_hosts causing no IP allocation
Hi Daniel,
I see following in your command
--dhcp-range=set:tag0,192.168.110.0,static,86400s
--dhcp-range=set:tag1,192.168.111.0,static,86400s
Is this expected? Was this command generated by the agent itself, or was
Dnsmasq manually started?
On Tuesday, June 9, 2015 4:41 AM, Kevin Benton blak...@gmail.com wrote:
Just to be sure, I assume we're focussing here on the issue that Daniel
reported
Yes.
To be clear, though, what code are you trying to reproduce on? Current master?
I was trying on 2014.1.3, which is the version I understand to be on Fuel 5.1.1.
I'm not clear whether that would qualify as 'concurrent', in the sense that
you have in mind.
It doesn't look like it based on the pseudocode. I was thinking of a condition
where a port is deleted nearly very quickly after it was created. Is that
possible with your test? If not, then my theory about out-of-order
notifications might not be any good.
On Tue, Jun 9, 2015 at 3:34 AM, Neil Jerram neil.jer...@metaswitch.com wrote:
On 09/06/15 01:15, Kevin Benton wrote:
I'm having difficulty reproducing the issue. The bug that Neil
referenced (https://bugs.launchpad.net/neutron/+bug/1192381) looks like
it was in Icehouse well before the 2014.1.3 release that looks like Fuel
5.1.1 is using.
Just to be sure, I assume we're focussing here on the issue that Daniel
reported (IP appears twice in Dnsmasq config), and for which I described a
possible corollary (Dnsmasq config size keeps growing), and NOT on the Another
DHCP agent problem that I mentioned below. :-)
BTW, now that I've reviewed the history of when my team saw this, I can say
that it was actually first reported to us with the 'IP appears twice in Dnsmasq
config' symptom - i.e. exactly the same as Daniel's case. The fact of the
Dnsmasq config increasing in size was noticed later.
I tried setting the agent report interval to something higher than the
downtime to make it seem like the agent is failing sporadically to the
server, but it's not impacting the notifications.
Makes sense - that's the effect of the fix for 1192381.
To be clear, though, what code are you trying to reproduce on? Current master?
Neil, does your testing where you saw something similar have a lot of
concurrent creation/deletion?
It was a test of continuously deleting and creating VMs, with this pseudocode:
thread_pool = new_thread_pool(size=30)
for x in range(0,30):
thread_pool.submit(create_vm)
thread_pool.wait_for_all_threads_to_complete()
while True:
time.sleep(5)
for x in range(0,int(random.random()*5)):
thread_pool.submit(randomly_delete_a_vm_and_create_a_new_one)
I'm not clear whether that would qualify as 'concurrent', in the sense that you
have in mind.
Regards,
Neil
On Mon, Jun 8, 2015 at 12:21 PM, Andrew Woodward awoodw...@mirantis.com
mailto:awoodw...@mirantis.com wrote:
Daniel,
This sounds familiar, see if this matches [1]. IIRC, there was
another issue like this that was might already address this in the
updates into Fuel 5.1.2 packages repo [2]. You can either update the
neutron packages from [2] Or try one of community builds for 5.1.2
[3]. If this doesn't resolve the issue, open a bug against MOS dev [4].
[1] https://bugs.launchpad.net/bugs/1295715
[2] http://fuel-repository.mirantis.com/fwm/5.1.2/ubuntu/pool/main/
[3] https://ci.fuel-infra.org/
[4] https://bugs.launchpad.net/mos/+filebug
On Mon, Jun 8, 2015 at 10:15 AM Neil Jerram
neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote:
Two further thoughts on this:
1. Another DHCP agent problem that my team noticed is that it
call_driver('reload_allocations') takes a bit of time (to
regenerate the
Dnsmasq config files, and to spawn a shell that sends a HUP
signal) -
enough so that if there is a fast steady rate of port-create and
port-delete notifications coming from the Neutron server, these can
build up in DHCPAgent's RPC queue, and then they still only get
dispatched one at a time. So the queue and the time delay
become longer
and longer.
I have a fix pending for this, which uses an extra thread to
read those
notifications off the RPC queue onto an internal queue, and then
batches
the call_driver('reload_allocations') processing when there is a
contiguous sequence of such notifications - i.e. only does the
config
regeneration and HUP once, instead of lots of times.
I don't think this is directly related to what you are seeing - but
perhaps there actually is some link that I am missing.
2. There is an interesting and vaguely similar thread currently
being
discussed about the L3 agent (subject L3 agent rescheduling
issue) -
about possible RPC/threading issues between the agent and the
Neutron
Re: [openstack-dev] Please Merge patches titled Merge Tag ...
On 2015-06-09 09:35:55 -0400 (-0400), Monty Taylor wrote: [...] We're going to re-run the process that generates the commits - when the new ones come in - please merge them to make the release team happy. [...] I've updated (after restoring if abandoned) all the pending release tag merge changes now. I've also included some helpful information in their commit messages and our automation has been improved to add the same additional detail in the future as well. https://review.openstack.org/#/q/status:open+topic:merge/release-tag,n,z Many are failing on unrelated oslo library release breakage at the moment (surfacing in grenade), but I'll recheck them once that's solved. -- Jeremy Stanley __ 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] (re)centralizing library release management
Until now we have encouraged project teams to prepare their own library releases as new versions of projects were needed. We've started running into a couple of problems with that, with releases not coming often enough, or at a bad time in the release cycle, or with version numbering not being applied consistently, or without proper announcements. To address these issues, the release management team is proposing to create a small team of library release managers to handle the process around all library releases (clients, non-application projects, middleware, Oslo libraries, etc.). This will give us a chance to collaborate and review the version numbers for new releases, as well as stay on top of stale libraries with fixes or features that sit unreleased for a period of time. It will also be the first step to creating an automated review process for release tags. The process still needs to be worked out, but I envision it working something like this: The release liaison/PTL for the project team submits a request for a new release, including the repo name, the SHA, the series (liberty, kilo, etc.), and the proposed version number. The release team checks the proposed version number against the unreleased changes up to that SHA, and then either updates it to reflect semver or uses it as it is provided. The release team would then handle the tag push and the resulting announcements. There would be a few conditions under which a new release might not be immediately approved, but really only when the gate is wedged and during freeze periods. The point of the change isn't to block releases, just ensure consistency and good timing. We have some tools to let us look for unreleased changes, and eventually we can set up a recurring job to build that report so we can propose releases to project teams with a large release backlog. That will likely come later, though. We can also pre-announce proposed releases if folks find that useful. We will need a small number of volunteers to join this team, and start building the required expertise in understanding the overall state of the project, and in semantic versioning. We do not necessarily want a liaison from every project -- think of this as the proto-team for the group that eventually has core reviewer rights on the release automation repository. Doug __ 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] [release][oslo] oslo.middleware release 2.0.0 (liberty)
Excerpts from doug's message of 2015-06-09 11:14:23 -0400: We are excited to announce the release of: oslo.middleware 2.0.0: Oslo Middleware library This release is part of the liberty release series. The changes in this version cause several projects to require manual updates to the paste.ini before/during the upgrade. We're going to revoke this version of the library and release a new one that restores the namespace package. The Oslo team will remove the package during the M cycle to give all deployers a chance to update their paste.ini files to not use the oslo namespace package. Doug __ 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] [infra] how to trigger a set of jenkins jobs
I would encourage you to take a look at zuul but if you prefer not to use it then I believe you can also achieve your use case just using Jenkins by setting up multiple jobs with the same trigger. The jenkins job builder tool will help you setup and manage those jobs. -Khai __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][vpnaas][barbican] What types of authentication to support?
Hi, There is a Request for Feature Enhancement [1] to support authentication certifications for VPNaaS IPSec site to site connections, by using Barbican, in a manner similar to what was done for LBaaS listeners. Currently, VPNaaS only supports pre-shared keys for authentication, but the reference StrongSwan implementation of VPN supports several types of authentication. [2] Looking at IPsec site-to-site connections, there are examples [3] for PSK and X.509 certificates. Should we just do X.509 certificates for now? Are there other methods that we should support? Can Barbican support such methods? The plan is to support other VPN types in the future (e.g. DM VPN), so we want to make sure this will be extendable. Suggestions/Comments/Concerns? Thanks! Paul Michali (pc_m) [1] https://bugs.launchpad.net/neutron/+bug/1459427 [2] https://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecrets [3] https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2Examples (see site-2-site) __ 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] [release][oslo] oslo.middleware release 2.0.0 (liberty)
On Tue, Jun 9, 2015 at 6:14 PM, d...@doughellmann.com wrote: We are excited to announce the release of: oslo.middleware 2.0.0: Oslo Middleware library And this broke the gate, but the fix is already working its way though the system. https://bugs.launchpad.net/grenade/+bug/1463478 This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.middleware For more details, please see the git log history below and: http://launchpad.net/oslo.middleware/+milestone/2.0.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.middleware Changes in oslo.middleware 1.3.0..2.0.0 --- bcbfceb Remove oslo namespace package Diffstat (except docs and test files) - oslo/__init__.py | 13 - oslo/middleware/__init__.py | 28 -- oslo/middleware/base.py | 13 - oslo/middleware/catch_errors.py | 13 - oslo/middleware/correlation_id.py | 13 - oslo/middleware/debug.py | 13 - oslo/middleware/request_id.py | 13 - oslo/middleware/sizelimit.py | 13 - setup.cfg | 4 -- 15 files changed, 429 deletions(-) __ 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] [infra] how to trigger a set of jenkins jobs
The origin concept of jenkins is one trigger one job. For example, the job neutron-unit-test-py27 could respond a new change set from neutron upstream. But the truth is that a gerrit event trigger a set of jenkins jobs: py27-unittest, pep8-check, and many dsvm jobs... How can I configure my jenkins like this? We use the https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin plugin to do this, we have a master jenkins job that fires on some trigger (git repo change etc), and then fires off a set of sub jobs that we want executed in response to that. (we use this via the JJB macro: http://docs.openstack.org/infra/jenkins-job-builder/builders.html#builders.trigger-builds - if you're using JJB to maintain your jobs) HTH, Simon. -- Simon McCartney E: si...@mccartney.ie M: +44 7710 836 915 __ 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] [Ironic] subteam status report
Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Drivers == iLO (wanyen) -- 3rd-party CI is ready but need to setup isloated network environment to roll it out Several specs are under review: - UEFI secure boot for pxe-ilo driver https://review.openstack.org/#/c/174295/ - Generic RAID configuration https://review.openstack.org/#/c/173214/ has two +2 but still needs workflow approval. - in-band RAD config https://review.openstack.org/#/c/173218/ - zapping support for iLO drivers https://review.openstack.org/#/c/145404/ - capabilitites should accept value as dictionary https://review.openstack.org/#/c/182934/ iRMC (naohirot) - https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z Status: Reactive (solicit for core team's review and approval) - iRMC Virtual Media Deploy Driver - Deploy Driver Base patch which implemented: - bp/irmc-virtualmedia-deploy-driver - bp/non-glance-image-refs - bp/automate-uefi-bios-iso-creation - On top of the base, following up patches implemented: - bp/local-boot-support-with-partition-images - bp/whole-disk-image-support - bp/ipa-as-default-ramdisk Status: Active - Enhance Power Interface for Soft Reboot and NMI - bp/enhance-power-interface-for-soft-reboot-and-nmi - The next work item currently iRMC team is investigating: - bp/ironic-node-properties-discovery Until next week, --ruby [0] https://etherpad.openstack.org/p/IronicWhiteBoard __ 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] [all][api] 1 new guideline entering freeze period
The API working group has one new guidelines that is entering the freeze period. We would like to ask all PTLs and CPLs, and other interested parties, to take a look at these reviews. We will use lazy consensus at the end of the freeze to merge them if there are no objections. The guideline up for review is: * Clarification on the return code when a server has a hard coded length limit https://review.openstack.org/#/c/181784/ thanks, mike __ 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] [Neutron] API Extensions - Namespace URLs
I wasn't planning on wiping them out for now since I'm leveraging a lot of the extension loading that exists so someone can remove the namespaces if they want. On Tue, Jun 9, 2015 at 1:12 PM, Salvatore Orlando sorla...@nicira.com wrote: Jay is pretty much right. In Neutron's case it is even more trivial. Somebody copied the extension manager from Nova, and a sort of extension interface with this namespace. And every neutron developer, including me felt compelled to filling that up with something that resembled an XML namespace URI (which often resolve to nowhere anyway). I think a patch for blanking out those namespace is a great low hanging fruit for new contributors. But on the other hand I'm pretty sure Kevin is wiping them out as a part of the Pecan refactor. Salvatore On 9 June 2015 at 20:33, Kevin Benton blak...@gmail.com wrote: I heard rumors that Oracle was going to introduce XML-as-a-service to OpenStack to make it enterprise-grade. If that's the case, we'll be ahead of everyone with our namespaces. On Jun 9, 2015 12:04 PM, Brandon Logan brandon.lo...@rackspace.com wrote: I believe XML support got removed from the API last cycle. From: Jay Pipes jaypi...@gmail.com Sent: Tuesday, June 9, 2015 1:08 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs On 06/08/2015 05:10 PM, Sean M. Collins wrote: Hi, Within each API extension in the neutron tree, there is a method: def get_namespace(cls): Which returns a string, containing a URL. snip I believe that they all 404. A dumb question to start, then progressively smarter questions: * What is the purpose of the URLs? They are the sad detritus left from XML support. * Should the URL point to documentation? Perhaps. * What shall we do about the actual URLs 404'ing? Honestly, I'd prefer the namespaces just be removed, but I'm not sure what Neutron's position is about XML and the REST API... Best, -jay __ 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 __ 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 -- Kevin Benton __ 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] Request to post to this list EOM
__ 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] [all] pbr release wedged things, fixed in 1.1.1.
There was a gap in test coverage of pbr, and a thought-ok change actually broke sphinx building. We've reverted the change and issued a point release, and are working on increasing coverage before we bring the change back in. -Rob We are thrilled to announce the release of: pbr 1.1.1: Python Build Reasonableness With source available at: http://git.openstack.org/cgit/openstack-dev/pbr For more details, please see the git log history below and: http://launchpad.net/pbr/+milestone/1.1.1 Please report issues through launchpad: http://bugs.launchpad.net/pbr Changes in pbr 1.1.0..1.1.1 --- e41a918 Revert Remove sphinx_config.init_values() manual call Diffstat (except docs and test files) - pbr/builddoc.py | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
