approach that aspect? As it's common code, should I actually be
looking to make these changes in Oslo first then porting them in?
Thanks,
Matthew Gilliard
[1]
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4702
[2]
https://github.com/openstack/nova/blob/master/nova/compute
that make sense?
On Thu, Feb 6, 2014 at 9:46 AM, Michael Still mi...@stillhq.com wrote:
On Thu, Feb 6, 2014 at 8:16 PM, Matthew Gilliard
matthew.gilli...@gmail.com wrote:
Hello everyone.
wrt these bugs: https://bugs.launchpad.net/nova/+bug/1276203
https://bugs.launchpad.net/nova/+bug
.
Matthew
On Thu, Feb 6, 2014 at 11:44 AM, Matthew Gilliard
matthew.gilli...@gmail.com wrote:
If there is agreement that it's a change worth making, then I expect
something like:
1/ Add a warning for users who use period of 0 or use the default. Both
in the literal sense of log.warning
As the stacks we are trying to stand up get more and more complicated,
the demands on developers' hardware is increasing. Currently if you need N
VMs for your devtest run, you will create N which are identically sized (
We (HP Helion) are completely fine with a change that reduces server load
and makes things more predictable. It would have been very hard to rely
heavily on the old behaviour. Thanks for adding me to the patch, too, Matt
Matthew
On Wed, May 21, 2014 at 4:40 PM, Doug Hellmann
(nstance_uuid) on those 2 methods.
I'm not very familiar with the neutron codebase though, and would
appreciate some feedback or discussion on how likely people think my
diagnosis and suggested fix are, and whether similar problems have been
found in the past.
Thanks,
Matthew Gilliard
(HP Cloud
I like measuring code metrics, and I definitely support Joe's change
here. I think of McCabe complexity as a proxy for testability and
readability of code, both of which are IMO actual real problems in the
nova codebase. If you are an experienced openstack dev you might find
the code easy to move
1/ assertFalse() vs assertEqual(x, False) - these are semantically
different because of python's notion of truthiness, so I don't think
we ought to make this a rule.
2/ expected/actual - incorrect failure messages have cost me more time
than I should admit to. I don't see any reason not to try to
Hi Matt, Nova,
I'll look into this.
Gilliard
On Thu, Dec 4, 2014 at 9:51 PM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On 12/4/2014 6:02 AM, Davanum Srinivas wrote:
+1 to @markmc's default is global value and override for project
specific key suggestion.
-- dims
On Wed, Dec
I just put up a quick pre-weekend POC at
https://review.openstack.org/#/c/139672/ - comments welcome on that
patch.
Thanks :)
On Fri, Dec 5, 2014 at 10:07 AM, Matthew Gilliard
matthew.gilli...@gmail.com wrote:
Hi Matt, Nova,
I'll look into this.
Gilliard
On Thu, Dec 4, 2014 at 9:51 PM
Sometimes, I want to ask the author of a patch about it on IRC.
However, there doesn't seem to be a reliable way to find out someone's
IRC handle. The potential for useful conversation is sometimes
missed. Unless there's a better alternative which I didn't find,
So, are we agreed that http://www.openstack.org/community/members/ is
the authoritative place for IRC lookups? In which case, I'll take the
old content out of https://wiki.openstack.org/wiki/People and leave a
message directing people where to look.
I don't have the imagination to use anything
I'll take the
old content out of https://wiki.openstack.org/wiki/People and leave a
message directing people where to look.
Yes, please, let me know if you need help.
Done.
to link
directly gerrit IDs to openstack.org profile URL
This may be possible with a little javascript hackery in
Hello Pasquale
The problem is that you are trying to add a new if/else branch into
a method which is already ~250 lines long, and has the highest
complexity of any function in the nova codebase. I assume that you
didn't contribute much to that complexity, but we've recently added a
limit to
Hello,
At the moment, both Libvirt [1] and VPNaaS [2] are down as having
meetings in #openstack-meeting-3 at 1500UTC on Tuesdays. Of course,
there can be only one - and it looks as if the VPN meeting is the one
that actually takes place there.
What's the status of the libvirt meetings? Have
As I understand it, novaclient would by default not pass the microversion
HTTP header (X-OpenStack-Compute-API-Version) so it would get the server's
MIN_VERSION, ie 2.1 for the foreseeable future. It would be
straightforward to add something like a --api-version=xx command line
argument, or it
F811 is not part of our hacking lib - it's in flake8. As far as I know,
it's not possible to selectively disable that for particular files or
methods. And as mentioned earlier in the list and when I asked in
#openstack-dev the feeling was that we don't want to disable F811 globally
because it's
I think that both ways of doing this should be supported.
Decorated private methods make sense if the different microversions
have nicely interchangeable bits of functionality but not if one of
the private methods would have to be a no-op. A method which just
passes is noise. Additionally there
The devref has merged:
http://docs.openstack.org/developer/nova/devref/api_microversions.html
There are a few corner cases being worked on now, but the information
in there should be enough to add a new API change version.
MG
On Fri, Feb 20, 2015 at 12:33 AM, Christopher Yeoh cbky...@gmail.com
John,
If there are no objections, I would like to volunteer myself as
API-WG liaison for Nova.
Matthew
On Thu, Apr 23, 2015 at 2:29 PM, John Garbutt j...@johngarbutt.com wrote:
On 22 April 2015 at 23:41, Jay Pipes jaypi...@gmail.com wrote:
On 04/22/2015 04:33 PM, Kyle Mestery wrote:
On
Dumb question from me, is there an easy way to get a view that filters out
specs that haven't been re-submitted against the liberty directory?
You can use a regex in the files: filter, so I think you mean:
Thanks for the clarification, is there a bug tracking this in libvirt
already?
Actually I don't think there is one, so feel free to file one
I took the liberty of doing so:
https://bugzilla.redhat.com/show_bug.cgi?id=1208588
On Wed, Mar 18, 2015 at 6:11 PM, Daniel P. Berrange
The change Dan refers to merged in Kilo. I assume that if you actually
found this problem then you're using an earlier OpenStack, so it's
worth noting that there's an outstanding backport:
https://review.openstack.org/#/c/176768/
Matthew
On Wed, May 20, 2015 at 3:21 AM, Daniel P. Berrange
23 matches
Mail list logo
