Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

2015-06-09 Thread Thomas Goirand
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?

2015-06-09 Thread Sebastien Han
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

2015-06-09 Thread Gareth
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

2015-06-09 Thread John Garbutt
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

2015-06-09 Thread Dirk Müller
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

2015-06-09 Thread Bob Ball
 -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

2015-06-09 Thread James Page
-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

2015-06-09 Thread Paul Bourke

+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

2015-06-09 Thread Thomas Goirand
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

2015-06-09 Thread Thomas Goirand
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

2015-06-09 Thread Thomas Goirand
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

2015-06-09 Thread Thomas Goirand
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

2015-06-09 Thread Thomas Goirand
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

2015-06-09 Thread Serg Melikyan
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

2015-06-09 Thread Neil Jerram

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

2015-06-09 Thread Thomas Goirand
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

2015-06-09 Thread Thomas Goirand
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

2015-06-09 Thread Kevin Benton
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

2015-06-09 Thread Kirill Zaitsev
+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

2015-06-09 Thread Neil Jerram

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

2015-06-09 Thread Kirill Zaitsev
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

2015-06-09 Thread Ekaterina Chernova
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)

2015-06-09 Thread 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

2015-06-09 Thread Michael Klishin
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

2015-06-09 Thread Flavio Percoco

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

2015-06-09 Thread Flavio Percoco

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

2015-06-09 Thread Andreas Jaeger

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

2015-06-09 Thread Dmitry Tantsur

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

2015-06-09 Thread Bhandaru, Malini K
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.

2015-06-09 Thread Vikas Choudhary

__
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

2015-06-09 Thread Ying Chun Guo

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`

2015-06-09 Thread Deepak Shetty
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

2015-06-09 Thread Morgan Fainberg


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

2015-06-09 Thread Flavio Percoco

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

2015-06-09 Thread Bhandaru, Malini K
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

2015-06-09 Thread gordon chung

 
 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

2015-06-09 Thread Victor Stinner

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

2015-06-09 Thread Davanum Srinivas
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

2015-06-09 Thread Kirill Zaitsev
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

2015-06-09 Thread Jay Pipes

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)

2015-06-09 Thread doug
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)

2015-06-09 Thread doug
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)

2015-06-09 Thread doug
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)

2015-06-09 Thread doug
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

2015-06-09 Thread Jeremy Stanley
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)

2015-06-09 Thread doug
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)

2015-06-09 Thread doug
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

2015-06-09 Thread Serg Melikyan
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

2015-06-09 Thread Tim Hinrichs
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`

2015-06-09 Thread Deepak Shetty
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)

2015-06-09 Thread doug
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

2015-06-09 Thread Neil Jerram

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)

2015-06-09 Thread doug
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)

2015-06-09 Thread doug
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

2015-06-09 Thread Emilien Macchi


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)

2015-06-09 Thread doug
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)

2015-06-09 Thread doug
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)

2015-06-09 Thread doug
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

2015-06-09 Thread Michael Krotscheck
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

2015-06-09 Thread Daniel P. Berrange
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

2015-06-09 Thread Paul Belanger

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)

2015-06-09 Thread doug
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

2015-06-09 Thread Mathieu Gagné
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

2015-06-09 Thread Neil Jerram

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

2015-06-09 Thread Bradley Jones (bradjone)
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

2015-06-09 Thread Dolph Mathews
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`

2015-06-09 Thread Thang Pham
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

2015-06-09 Thread Asha Seshagiri
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

2015-06-09 Thread Michael Klishin
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

2015-06-09 Thread Peter Pouliot
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

2015-06-09 Thread Doug Hellmann
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

2015-06-09 Thread Michael Krotscheck
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

2015-06-09 Thread Paul Bourke
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...

2015-06-09 Thread Thierry Carrez
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?

2015-06-09 Thread Chris Friesen

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

2015-06-09 Thread Thai Q Tran
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)

2015-06-09 Thread doug
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

2015-06-09 Thread Emilien Macchi
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

2015-06-09 Thread Mike Bayer



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

2015-06-09 Thread Roman Bogorodskiy
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

2015-06-09 Thread Daniel P. Berrange
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

2015-06-09 Thread Adam Young

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] (re)centralizing library release management

2015-06-09 Thread Robert Collins
I volunteer for the team.
On 10 Jun 2015 5:25 am, Doug Hellmann d...@doughellmann.com wrote:

 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

__
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

2015-06-09 Thread Brandon Logan
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

2015-06-09 Thread Mike Bayer



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

2015-06-09 Thread Steven Dake (stdake)
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

2015-06-09 Thread Anita Kuno
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] [Neutron] API Extensions - Namespace URLs

2015-06-09 Thread Jay Pipes

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


Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x

2015-06-09 Thread Joe Gordon
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

2015-06-09 Thread Shraddha Pandhe
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 ...

2015-06-09 Thread Jeremy Stanley
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

2015-06-09 Thread Doug Hellmann
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)

2015-06-09 Thread Doug Hellmann
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

2015-06-09 Thread Zaro
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?

2015-06-09 Thread Paul Michali
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)

2015-06-09 Thread Joe Gordon
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] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC

2015-06-09 Thread Jeff Peeler

On Mon, Jun 08, 2015 at 05:15:54PM +, Steven Dake (stdake) 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.


Both 1600 and 1700 UTC are fine for me.

Jeff

__
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

2015-06-09 Thread Simon McCartney

 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

2015-06-09 Thread Ruby Loo
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

2015-06-09 Thread michael mccune
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


  1   2   >