Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-08 Thread Matthew Booth
On 07/08/14 18:54, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote: In any case, the operative point is that CONF.attribute must always be evaluated inside run-time code, never at module load time. ...unless you call register_opts() safely, which is what I'm

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-08 Thread Matthew Booth
On 07/08/14 19:02, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 17:41 +0100, Matthew Booth wrote: ... or arg is an object which defines __nonzero__(), or defines __getattr__() and then explodes because of the unexpected lookup of a __nonzero__ attribute. Or it's False (no quotes when printed

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-08 Thread Matthew Booth
On 08/08/14 11:04, Matthew Booth wrote: On 07/08/14 18:54, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote: In any case, the operative point is that CONF.attribute must always be evaluated inside run-time code, never at module load time. ...unless you call

[openstack-dev] [vmware] Canonical list of os types

2014-08-14 Thread Matthew Booth
a canonical list of valid values? Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

2014-08-15 Thread Matthew Booth
@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Matthew Booth Red Hat Engineering

Re: [openstack-dev] [nova] running pep8 tests much faster

2014-08-18 Thread Matthew Booth
-i) on to base. After applying each patch it will run each of the 2 given commands. If either fails it will pause. After resolving any issues you can continue with 'git rebase --continue'. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490

[openstack-dev] Criteria for giving a -1 in a review

2014-08-21 Thread Matthew Booth
future feature Lets avoid premature generalisation. We can always generalise as part of landing the future feature. Any more of these? Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441

Re: [openstack-dev] [vmware] Canonical list of os types

2014-09-01 Thread Matthew Booth
On 30/08/14 03:45, Steve Gordon wrote: - Original Message - From: Matthew Booth mbo...@redhat.com On 14/08/14 12:41, Steve Gordon wrote: - Original Message - From: Matthew Booth mbo...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev

[openstack-dev] [vmware][nova][FFE] vmware-spawn-refactor

2014-09-04 Thread Matthew Booth
, and has been given +1 by VMware CI multiple times. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list

Re: [openstack-dev] [vmware][nova][FFE] vmware-spawn-refactor

2014-09-04 Thread Matthew Booth
On 04/09/14 14:46, Daniel P. Berrange wrote: On Thu, Sep 04, 2014 at 02:09:26PM +0100, Matthew Booth wrote: I'd like to request a FFE for the remaining changes from vmware-spawn-refactor. They are: https://review.openstack.org/#/c/109754/ https://review.openstack.org/#/c/109755/ https

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

2014-09-09 Thread Matthew Booth
is a primary cause of technical debt, will adding more steps to it improve the situation? I hope the answer is obvious. And I'll be honest, I found the suggestion more than a little patronising. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID

[openstack-dev] [all] In defence of faking

2014-09-22 Thread Matthew Booth
to * However, there are situations where it's a good choice Thanks for reading :) Matt [1] There are other ways to skin this cat, but ultimately if you aren't actually spinning up a vSphere server, you're modelling it somehow. -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone

[openstack-dev] [Nova][vmware] A new VMwareAPISession

2014-02-06 Thread Matthew Booth
this, btw. -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin

Re: [openstack-dev] [Nova][vmware] A new VMwareAPISession

2014-02-06 Thread Matthew Booth
additional task. Matt Thanks Gary On 2/6/14 12:43 PM, Matthew Booth mbo...@redhat.com wrote: There's currently an effort to create a common internal API to the vSphere/ESX API: https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.ne t/oslo/%2Bspec/vmware-apik=oIvRg1

[openstack-dev] pep8 barfs on long URL

2014-02-07 Thread Matthew Booth
URLs? Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http

[openstack-dev] [nova] An analysis of code review in Nova

2014-02-25 Thread Matthew Booth
fix. A less obvious fix might involve a process which allows developers to work on a fork which is periodically merged, rather like the kernel. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

[openstack-dev] [nova][vmware] Locking: A can of worms

2014-03-07 Thread Matthew Booth
will make a whole class of problems go away. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [nova] An analysis of code review in Nova

2014-03-13 Thread Matthew Booth
On 12/03/14 18:28, Matt Riedemann wrote: On 2/25/2014 6:36 AM, Matthew Booth wrote: I'm new to Nova. After some frustration with the review process, specifically in the VMware driver, I decided to try to visualise how the review process is working across Nova. To that end, I've created 2

[openstack-dev] [nova][ironic] BaremetalHostManager unused?

2014-04-04 Thread Matthew Booth
, but it might be worth a quick look. Incidentally, the tests seem to populate service_states in fake, so the behaviour of the automated tests probably isn't reliable. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600

Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

2014-04-07 Thread Matthew Booth
obviously has other options. The fact that we can't migrate a VM between 2 clusters is clearly a bug. Whether a single Nova should manage multiple clusters is an open question, but it should be able to treat them as multiple targets. It's not fundamentally wrong, though. Matt -- Matthew Booth, RHCA

Re: [openstack-dev] [policy] Let's make topics mandatory for openstack-dev

2013-12-05 Thread Matthew Booth
On Thu, 2013-12-05 at 11:35 +0200, Roman Prykhodchenko wrote: Hi folks, Open Stack community grows continuously bringing more people and so new initiatives and new projects. This growing amount of people, initiatives and projects causes increasing the amount of discussions in our mailing

[openstack-dev] [nova] Distributed locking

2014-06-12 Thread Matthew Booth
~= hypervisor -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http

Re: [openstack-dev] [nova] Distributed locking

2014-06-12 Thread Matthew Booth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/06/14 15:35, Julien Danjou wrote: On Thu, Jun 12 2014, Matthew Booth wrote: We have a need for a distributed lock in the VMware driver, which I suspect isn't unique. Specifically it is possible for a VMware datastore to be accessed via

Re: [openstack-dev] [nova] Distributed locking

2014-06-13 Thread Matthew Booth
on the different strategies and such). Nice list of implementation pros/cons. Matt -Josh -Original Message- From: Matthew Booth mbo...@redhat.com Organization: Red Hat Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date

Re: [openstack-dev] [nova] Distributed locking

2014-06-17 Thread Matthew Booth
it should be able to have a fencing race with the possible lock holder before continuing. This is obviously undesirable, as you will probably be fencing an otherwise correctly functioning node, but it will be correct. Matt -Original Message- From: Matthew Booth mbo...@redhat.com

[openstack-dev] [nova] A modest proposal to reduce reviewer load

2014-06-17 Thread Matthew Booth
. It would be removed for abuse. Is this practical? Would it help? Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing

Re: [openstack-dev] [nova] A modest proposal to reduce reviewer load

2014-06-17 Thread Matthew Booth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/06/14 12:36, Sean Dague wrote: On 06/17/2014 07:23 AM, Daniel P. Berrange wrote: On Tue, Jun 17, 2014 at 11:04:17AM +0100, Matthew Booth wrote: We all know that review can be a bottleneck for Nova patches.Not only that, but a patch lingering

Re: [openstack-dev] [nova] A modest proposal to reduce reviewer load

2014-06-18 Thread Matthew Booth
] This series is very nice: https://review.openstack.org/#/c/98604/ [2] In fact, I'm aware of a significant amount of cleanup which hasn't happened because of this. -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A

Re: [openstack-dev] [nova] A modest proposal to reduce reviewer load

2014-06-18 Thread Matthew Booth
. Review has significant benefits, but also a large cost, and it doesn't have all the answers. The answer is not always more review: there are other tools in the box. Imagine we spent 50% of the time we spend on review writing tempest tests instead. Matt - -- Matthew Booth Red Hat Engineering

Re: [openstack-dev] [nova] A modest proposal to reduce reviewer load

2014-06-19 Thread Matthew Booth
interest :) This is all good stuff, but by the sounds of it experimenting in gerrit isn't likely to be simple. Remember, though, that the relevant metric is code quality, not review rate. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG

Re: [openstack-dev] [nova] A modest proposal to reduce reviewer load

2014-06-19 Thread Matthew Booth
On 19/06/14 13:22, Mark McLoughlin wrote: On Thu, 2014-06-19 at 09:34 +0100, Matthew Booth wrote: On 19/06/14 08:32, Mark McLoughlin wrote: Hi Armando, On Tue, 2014-06-17 at 14:51 +0200, Armando M. wrote: I wonder what the turnaround of trivial patches actually is, I bet you it's very very

[openstack-dev] [nova][vmware] Future of Vim and PBM in Nova: summary of IRC discussion

2014-06-20 Thread Matthew Booth
proposing any backwards incompatible changes at the moment there is no current incentive to bring this forward. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

[openstack-dev] [nova] Usage of _L?() translation functions

2014-06-20 Thread Matthew Booth
advice. Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http

Re: [openstack-dev] [nova] Jenkins failure ... nova-docs UNSTABLE

2014-06-23 Thread Matthew Booth
: https://bugs.launchpad.net/nova/+bug/1333232 Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack

[openstack-dev] [nova][vmware] Convert to rescue by adding the rescue image and booting from it

2014-07-10 Thread Matthew Booth
://review.openstack.org/#/c/106082/ -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [nova][vmware] Convert to rescue by adding the rescue image and booting from it

2014-07-14 Thread Matthew Booth
On 11/07/14 12:36, Daniel P. Berrange wrote: On Fri, Jul 11, 2014 at 12:30:19PM +0100, John Garbutt wrote: On 10 July 2014 16:52, Matthew Booth mbo...@redhat.com wrote: Currently we create a rescue instance by creating a new VM with the original instance's image, then adding the original

Re: [openstack-dev] [nova][vmware] Convert to rescue by adding the rescue image and booting from it

2014-07-14 Thread Matthew Booth
from that, though, I believe you could create a generic rescue image which would be good for most/all Linux instances at the very least. In fact, there are plenty of examples of generic rescue images out there already. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone

Re: [openstack-dev] [nova] Manage multiple clusters using a single nova service

2014-07-15 Thread Matthew Booth
-- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org

[openstack-dev] [gate] Automatic elastic rechecks

2014-07-17 Thread Matthew Booth
, every person seeing this would diligently check that the fingerprint match was accurate before submitting a recheck request. In the real world, how about we just do it automatically? Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG

[openstack-dev] [vmware] Mine Sweeper failures, logs are 404s

2014-07-17 Thread Matthew Booth
going on here? Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

[openstack-dev] [nova][vmware] VMware team review of spawn refactor patches

2014-07-18 Thread Matthew Booth
should hopefully be just a quick re-review. Note to self: When rebasing, make a note of merge conflicts and add a summary of required changes to a comment in gerrit. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05

[openstack-dev] [gate] The gate: a failure analysis

2014-07-21 Thread Matthew Booth
. As a project we need to understand the importance of CI failures. We need a proper negotiation with contributors to staff a team dedicated to the problem. We can then use the review process to ensure that the right people have an incentive to prioritise bug fixes. Matt -- Matthew Booth Red Hat

[openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-07 Thread Matthew Booth
= cfg.CONF CONF.import_opt('foo_opt', 'foo') def bar_func(arg=CONF.foo_opt): pass --- Even if it's old news it's worth a refresher because it was a bit of a headscratcher. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733

Re: [openstack-dev] [nova][oslo] oslo.config and import chains (a proposal to update the style guidelines for imports)

2014-08-07 Thread Matthew Booth
On 07/08/14 12:15, Matthew Booth wrote: I'm sure this is well known, but I recently encountered this problem for the second time. --- foo: import oslo.config as cfg import bar CONF = cfg.CONF CONF.register_opts('foo_opt') --- bar: import oslo.config as cfg CONF = cfg.CONF

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-07 Thread Matthew Booth
On 07/08/14 16:27, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: A (the?) solution is to register_opts() in foo before importing any modules which might also use oslo.config. Actually, I disagree. The real problem here is the definition of bar_func

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-07 Thread Matthew Booth
On 07/08/14 17:11, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 10:55 -0500, Matt Riedemann wrote: On 8/7/2014 10:27 AM, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: A (the?) solution is to register_opts() in foo before importing any modules which might

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-07 Thread Matthew Booth
. These are tricky, case-by-case workarounds to a general problem which can be solved by simply calling register_opts() in a place where it's guaranteed to be safe. Is there any reason not to call register_opts() before importing other modules? Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

2014-08-07 Thread Matthew Booth
On 07/08/14 17:39, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 17:27 +0100, Matthew Booth wrote: On 07/08/14 16:27, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: A (the?) solution is to register_opts() in foo before importing any modules which might also

[openstack-dev] [nova][vmware] iSCSI and managing cluster-wide config

2014-05-30 Thread Matthew Booth
not convinced it's possible. -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

[openstack-dev] [nova][vmware] VMware CI should vote -1 on test failures

2014-10-08 Thread Matthew Booth
purpose. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http

[openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-12 Thread Matthew Booth
, Instance, InstanceGroup, and Flavor perform multiple updates on save(). I would apply the same rule to the sub-updates, and also move them into a single transaction such that the updates are atomic. Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-12 Thread Matthew Booth
these non-atomic updates, of course :) Thanks, Matt - -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -BEGIN PGP SIGNATURE- Version: GnuPG v1

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-13 Thread Matthew Booth
-- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-13 Thread Matthew Booth
On 12/11/14 23:23, Mike Bayer wrote: On Nov 12, 2014, at 10:56 AM, Matthew Booth mbo...@redhat.com wrote: For brevity, I have conflated what happens in object.save() with what happens in db.api. Where the code lives isn't relevant here: I'm only looking at what happens. Specifically

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-13 Thread Matthew Booth
us between multiple, remote transactions. This is one of the motivations for compare-and-swap over row locking on read. Another is that the length of some API calls makes holding a row lock for that long undesirable. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-13 Thread Matthew Booth
going with). Dan, Note that this model, as I understand it, would conflict with storing context in NovaObject. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-13 Thread Matthew Booth
by an object, long after the context has been resolved, the call has been remoted, etc. Can we guarantee that the lifetime of a context object in conductor is a single rpc call, and that the object cannot be referenced from any other thread? Seems safer just to pass it around. Matt - -- Matthew Booth

[openstack-dev] [nova] Undead DB objects: ProviderFirewallRule and InstanceGroupPolicy?

2014-11-13 Thread Matthew Booth
at all. _validate_instance_group_policy() in compute manager seems to be doing something else. Are these undead relics in need of a final stake through the heart, or is something else going on here? Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-14 Thread Matthew Booth
transaction on the remote end. I think we agree on this. Matt - -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -BEGIN PGP SIGNATURE- Version: GnuPG v1

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-14 Thread Matthew Booth
have 'seen' this pattern in more places than it actually exists. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

2014-11-14 Thread Matthew Booth
at the object level would be a useful mechanism for safety across multiple rpc calls. Matt - -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -BEGIN PGP SIGNATURE- Version: GnuPG v1

[openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-19 Thread Matthew Booth
other than sqlalchemy, so we should probably ditch it and promote it to db/api.py. -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: [openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-20 Thread Matthew Booth
ensure the same logic applies when we save the info cache directly? It's certainly achievable, but it's just adding to the mess. My proposal is safe, efficient, and simple. Matt - -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733

Re: [openstack-dev] [oslo] [nova] [all] potential enginefacade adjustment - can everyone live with this?

2015-01-26 Thread Matthew Booth
_TransactionContextManager, and moving code directly into RequestContext would be a very invasive coupling. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

[openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-04 Thread Matthew Booth
-cluster-and-galera/ [3] http://www.percona.com/blog/2013/03/03/investigating-replication-latency-in-percona-xtradb-cluster/ -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

[openstack-dev] [oslo.db][nova] Deprecating use_slave in Nova

2015-01-30 Thread Matthew Booth
comments on the usefulness of slave databases, and the desirability of making maximum use of them? Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: [openstack-dev] [oslo.db][nova] Use of asynchronous slaves in Nova (was: Deprecating use_slave in Nova)

2015-02-02 Thread Matthew Booth
On 30/01/15 19:06, Mike Bayer wrote: Matthew Booth mbo...@redhat.com wrote: At some point in the near future, hopefully early in L, we're intending to update Nova to use the new database transaction management in oslo.db's enginefacade. Spec: http://git.openstack.org/cgit/openstack

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Matthew Booth
On 04/02/15 19:04, Jay Pipes wrote: On 02/04/2015 12:05 PM, Sahid Orentino Ferdjaoui wrote: On Wed, Feb 04, 2015 at 04:30:32PM +, Matthew Booth wrote: I've spent a few hours today reading about Galera, a clustering solution for MySQL. Galera provides multi-master 'virtually synchronous

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Matthew Booth
contention even in single master. I don't think so, but you can certainly still have real deadlocks. They're bugs, though. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: [openstack-dev] [nova] stuck patches at the nova IRC meeting

2015-02-05 Thread Matthew Booth
fastest but ask people not to interrupt. +1 Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 __ OpenStack

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Matthew Booth
safer to fail. Matt [1] Standard caveats apply. -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 __ OpenStack

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Matthew Booth
:1 request:transaction relationship. We're moving towards it, but potentially long running requests will always have to use multiple transactions. However, I take your point. I think retry on transaction failure is something which would benefit from standard handling in a library. Matt -- Matthew

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-05 Thread Matthew Booth
deadlocks is hard enough work. Adding the possibility that they might not even be there is just evil. Incidentally, we're currently looking to replace this stuff with some new code in oslo.db, which is why I'm looking at it. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone

[openstack-dev] [all][oslo.db] Repeatable Read considered harmful

2015-02-06 Thread Matthew Booth
to dramatically increase. We should standardise on read committed. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: [openstack-dev] [vmware][nova] Prevent HA configuration with different hostnames

2015-02-11 Thread Matthew Booth
, which is what I've proposed. Matt Thanks Gary On 2/11/15, 5:31 PM, Matthew Booth mbo...@redhat.com wrote: I just posted this: https://review.openstack.org/#/c/154907/ as an alternative fix for critical bug: https://bugs.launchpad.net/nova/+bug/1419785 I've just knocked this up

Re: [openstack-dev] [vmware][nova] Prevent HA configuration with different hostnames

2015-02-11 Thread Matthew Booth
. No. There are no duplicates. -Sylvain On 2/11/15, 5:55 PM, Matthew Booth mbo...@redhat.com wrote: On 11/02/15 15:49, Gary Kotton wrote: Hi, I do not think that that is a healthy solution. That effectively would render a cluster down if the compute node goes down. That would be a real disaster

[openstack-dev] [vmware][nova] Prevent HA configuration with different hostnames

2015-02-11 Thread Matthew Booth
, leaving inconsistent state in its wake as it runs. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-10 Thread Matthew Booth
to say the opposite. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 __ OpenStack Development Mailing

[openstack-dev] [nova] The strange case of osapi_compute_unique_server_name_scope

2015-02-19 Thread Matthew Booth
on MySQL. See this series if you're interested: https://review.openstack.org/#/c/156299/ [2] For specifics, see my ramblings here: https://review.openstack.org/#/c/141115/7/nova/db/sqlalchemy/api.py,cm line 2547 -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK

Re: [openstack-dev] [nova] Libguestfs: possibility not to use it, even when installed ?

2015-02-19 Thread Matthew Booth
-- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 __ OpenStack Development Mailing List (not for usage questions

[openstack-dev] [nova][vmware][ironic] Configuring active/passive HA Nova compute

2015-02-20 Thread Matthew Booth
writer in certain circumstances. That problem would have to be handled separately, perhaps at the messaging layer. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

Re: [openstack-dev] [nova] The strange case of osapi_compute_unique_server_name_scope

2015-02-20 Thread Matthew Booth
On 19/02/15 18:57, Jay Pipes wrote: On 02/19/2015 05:18 AM, Matthew Booth wrote: Nova contains a config variable osapi_compute_unique_server_name_scope. Its help text describes it pretty well: When set, compute API will consider duplicate hostnames invalid within the specified scope

[openstack-dev] [nova][vmware] HA and image caching

2015-02-19 Thread Matthew Booth
to have the same 'host'. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 __ OpenStack Development Mailing

Re: [openstack-dev] [all] Theory of Testing Cross Project Spec

2015-02-09 Thread Matthew Booth
guidelines for comments on all reviews. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 __ OpenStack

Re: [openstack-dev] [all][oslo.db][nova] TL; DR Things everybody should know about Galera

2015-02-11 Thread Matthew Booth
On 10/02/15 18:29, Jay Pipes wrote: On 02/10/2015 09:47 AM, Matthew Booth wrote: On 09/02/15 18:15, Jay Pipes wrote: On 02/09/2015 01:02 PM, Attila Fazekas wrote: I do not see why not to use `FOR UPDATE` even with multi-writer or Is the retry/swap way really solves anything here. snip Am I

[openstack-dev] [nova] Nova compute will delete all your instances if you change its hostname

2015-02-27 Thread Matthew Booth
://review.openstack.org/#/c/159481/ -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 __ OpenStack Development Mailing List

Re: [openstack-dev] [nova][vmware][ironic] Configuring active/passive HA Nova compute

2015-02-23 Thread Matthew Booth
On 20/02/15 11:48, Matthew Booth wrote: Gary Kotton came across a doozy of a bug recently: https://bugs.launchpad.net/nova/+bug/1419785 In short, when you start a Nova compute, it will query the driver for instances and compare that against the expected host of the the instance according

Re: [openstack-dev] [nova][vmware][ironic] Configuring active/passive HA Nova compute

2015-02-23 Thread Matthew Booth
On 23/02/15 12:13, Gary Kotton wrote: On 2/23/15, 2:05 PM, Matthew Booth mbo...@redhat.com wrote: On 20/02/15 11:48, Matthew Booth wrote: Gary Kotton came across a doozy of a bug recently: https://bugs.launchpad.net/nova/+bug/1419785 In short, when you start a Nova compute

Re: [openstack-dev] [nova][vmware][ironic] Configuring active/passive HA Nova compute

2015-02-25 Thread Matthew Booth
On 25/02/15 11:51, Radoslav Gerganov wrote: On 02/23/2015 03:18 PM, Matthew Booth wrote: On 23/02/15 12:13, Gary Kotton wrote: On 2/23/15, 2:05 PM, Matthew Booth mbo...@redhat.com wrote: On 20/02/15 11:48, Matthew Booth wrote: Gary Kotton came across a doozy of a bug recently: https

Re: [openstack-dev] [nova] The strange case of osapi_compute_unique_server_name_scope

2015-02-23 Thread Matthew Booth
get the online schema changes, but for the moment it seems like a lot of complication for a relatively small problem. Do you use the global or project scope, btw? Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05

Re: [openstack-dev] [nova][vmware][ironic] Configuring active/passive HA Nova compute

2015-02-26 Thread Matthew Booth
On 25/02/15 20:18, Joe Gordon wrote: On Fri, Feb 20, 2015 at 3:48 AM, Matthew Booth mbo...@redhat.com mailto:mbo...@redhat.com wrote: Gary Kotton came across a doozy of a bug recently: https://bugs.launchpad.net/nova/+bug/1419785 In short, when you start a Nova compute

[openstack-dev] [nova] Unvalidated user input passed to functions

2015-05-15 Thread Matthew Booth
and commit_top arguments to virt_dom.blockCommit() are unvalidated. Does python have anything like perl's taint mode? If so, it might be worth investigating its use. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A

Re: [openstack-dev] [Nova] PTL Candidacy

2015-04-02 Thread Matthew Booth
on how to improve core reviewer throughput in the next cycle? Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

[openstack-dev] [all] Any other downstream developers having problems with pbr?

2015-06-26 Thread Matthew Booth
I wrote this: https://review.openstack.org/#/c/195983/1/tools/de-pbr.py,cm Ideally we'd fix PBR, but this seems to be expected behaviour. Thoughts? Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600

[openstack-dev] [all] Script to merge sort log files

2015-07-15 Thread Matthew Booth
I expect there are several existing solutions to this problem, but here's mine (attached). Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 log_merge.sh Description

[openstack-dev] [oslo.messaging] State wrapping in the MessageHandlingServer

2015-11-10 Thread Matthew Booth
My patch to MessageHandlingServer is currently being reverted because it broke Nova tests: https://review.openstack.org/#/c/235347/ Specifically it causes a number of tests to take a very long time to execute, which ultimately results in the total build time limit being exceeded. This is very

Re: [openstack-dev] [oslo.messaging] State wrapping in the MessageHandlingServer

2015-11-11 Thread Matthew Booth
On Tue, Nov 10, 2015 at 6:46 PM, Joshua Harlow <harlo...@fastmail.com> wrote: > Matthew Booth wrote: > >> My patch to MessageHandlingServer is currently being reverted because it >> broke Nova tests: >> >> https://review.openstack.org/#/c/235347/ >> &

[openstack-dev] Fwd: [nova][mistral] Automatic evacuation as a long running task

2015-10-19 Thread Matthew Booth
Accidentally sent this privately. -- Forwarded message -- From: Matthew Booth <mbo...@redhat.com> Date: Fri, Oct 9, 2015 at 6:14 PM Subject: Re: [openstack-dev] [nova][mistral] Automatic evacuation as a long running task To: "Deja, Dawid" <dawid.d...@intel.c

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

2015-10-07 Thread Matthew Booth
On Fri, Sep 25, 2015 at 3:44 PM, Ihar Hrachyshka wrote: > Hi all, > > releases are approaching, so it’s the right time to start some bike > shedding on the mailing list. > > Recently I got pointed out several times [1][2] that I violate our commit > message requirement [3]

Re: [openstack-dev] [nova][mistral] Automatic evacuation as a long running task

2015-10-06 Thread Matthew Booth
Hi, Roman, Evacuated has been on my radar for a while and this post has prodded me to take a look at the code. I think it's worth starting by explaining the problems in the current solution. Nova client is currently responsible for doing this evacuate. It does: 1. List all instances on the

  1   2   >