the transition to a saner quota management system much easier
> > and straightforward.
I'm fine with that plan, speaking as the original developer; as I say,
I don't think Rackspace ever utilized the functionality anyway, and if
no one else pipes up saying t
The only way I can imagine stopping these errors in the future would be
to double-up on the pep8 check: have the gate run pep8 under both
Python 2 and Python 3.
--
Kevin L. Mitchell
signature.asc
Description: This is a digitally signed message part
__
ng new contributors to Nova get involved which helps grow our
> contributor base.
+1 from me
--
Kevin L. Mitchell
signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing List
oblem in keystone shouldn't require a version bump in
this case: it _is_ a breakage that's being fixed.
--
Kevin L. Mitchell
signature.asc
Description: This is a digitally signed message part
__
OpenStack Development M
deployer would view as a bug, if they encountered it, and because it
was introduced prior to a named final release.
--
Kevin L. Mitchell
signature.asc
Description: This is a digitally signed message part
__
OpenStack Develo
On Fri, 2017-08-04 at 12:26 -0700, Boris Pavlovic wrote:
> By the way stevedore is really providing very bad plugin experience
> and should not be used definitely.
Perhaps entrypointer[1]? ;)
[1] https://pypi.python.org/pypi/entrypointer
--
Kevin L. Mitchell
signature.asc
Description
ut. If that's the case, that may help provide a solution to
translate user-visible messages while leaving logs untranslated.
--
Kevin L. Mitchell
signature.asc
Description: This is a digitally signed message part
__
Ope
e your thoughts?
When the translators go to translate, they generally only get to see
what's inside _(), so #2 is a no-go for translations, and #3 also is a
no-go.
--
Kevin L. Mitchell
signature.asc
Description: This is a digitally signed message part
to
be the #3 largest IRC network at the time. Fixing *that* was fun :)
--
Kevin L. Mitchell
signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing List (not for usage que
On Fri, 2016-12-02 at 09:22 -0600, Matt Riedemann wrote:
> I'm proposing that we add Stephen Finucane to the nova-core team.
+1 from me.
--
Kevin L. Mitchell
signature.asc
Description: This is a digitally signed mess
w, '/' can be used if it's URL
encoded, but I agree that that is non-ideal. How about a syntax
something like:
?finished_at=between:ISO_DATE_A@ISO_DATE_B&finished_at=between:ISO_DATE_C@ISO_DATE_
ntribute to dateutil than to
> put the function in a library not meant for anyone else outside of
> OpenStack to use.
You might also want to look at the timestring library…
--
Kevin L. Mitchell
signature.asc
Description: This is a digitally signed message part
__
and plumbing to use that, which sucks, because it's all very complicated.
>
> So I think I'm going to start a pet project of rooting this stuff out
> again, starting with nova.context.RequestContext.quota_class, unless
> anyone has a good reason we should keep this in tree
key, would it make any sense at all to add
additional keys? We could add a 'warnings' key in that top-level
dictionary that could document deprecations, among other things.
(That said, /capabilities or equivalent would probably be superior for
this particular case…)
--
Kevin L. Mit
several backoff
strategies. Of course, it's a decorator-based backoff implementation,
whereas I tend to implement iterator-based solutions, but there may
already be a solution in that space as well…
--
Kevin L. Mitchell
signature.asc
Description: This is a digitall
nfortunately, we weren't able to get priority for the project,
and I'm afraid it's probably not going to go anywhere now :/
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for u
g the other distracting
elements, such as schwag and giveaways…
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
tenant with a name
or ID of 'admin' exists." Anyone have any insights into why "admin"
would be missing from novaclient's functional test suite?
--
Kevin L. Mitchell
Rackspace
__
OpenSta
I think the
first phase is essentially complete at this point, but I think Chris is
right that it's high time to decide whether the guidelines are normative
or informative…and my vote would be for normative, and with a focus on
the API consumer. After all, an API is useless if it's a pain
plugins to use more recent versions of Python, we're going to
have to warn the operator community about the consequences well in
advance, so that all the issues can be worked out…
--
Kevin L. Mitchell
Rackspace
__
Ope
o apply to a tenant when there's no specific quota for that
tenant in its database. That's why you're getting a reasonable-looking
set of quota information.
--
Kevin L. Mitchell
Rackspace
__
OpenStack Developm
added unless the corresponding
nova change has been merged…
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject
prone to race conditions that are not a problem
for other quota types.
(For reference, the AbsoluteResource quotas are metadata_items,
injected_files, injected_file_content_bytes, and
injected_file_path_bytes; everything else is a ReservableResource.)
--
Kev
ting. However, I'd like to start off by asking
if "quota" is the correct concept? It might be worthwhile to make a
detour and consider what the problem is we're actually trying to solve.
I think in the end it'll still end up being recognizably "quota", but I
think it
ad suggesting what you could think of as an audience *class*—this
notification is intended for metrics consumers, this one is intended for
log monitors, etc. That kind of data could be included in the actual
notification, so you still have a single notif
o.i18n, oslo.serialization, and oslo.utils. If we drop
Python 2.6 compatibility on any of those three, we would also have to
drop it from novaclient (and potentially other clients). Perhaps we
need to have a discussion about whether the clients still need to
support Python 2.6?
--
Kevin L. Mitchell
Rac
On Mon, 2015-10-12 at 12:16 -0400, Sean Dague wrote:
> On 10/12/2015 11:54 AM, Kevin L. Mitchell wrote:
> > Functional tests on novaclient (gate-novaclient-dsvm-functional) have
> > started failing consistently. The test failures all seem to be for an
> > HTTP 300, which
address the problem?
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin
y thrown away the scalability
that deploying multiple schedulers was supposed to buy you.
[1] https://en.wikipedia.org/wiki/CAP_theorem
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage question
On Fri, 2015-10-02 at 11:00 -0400, Sean Dague wrote:
> On 10/02/2015 10:53 AM, Kevin L. Mitchell wrote:
> > The Pillow-breaking-gate issue was related to having doc dependencies
> > listed in the test-requirements.txt; however, those dependencies are not
> > needed for te
ntain only the doc dependencies? The appropriate doc environments in
tox.ini would then need to be extended to pull in that file, and of
course the global requirements tooling would have to be enhanced to
recognize the new file as well.
--
Kevin L. Mitchell
On Thu, 2015-10-01 at 15:53 -0700, Clark Boylan wrote:
> On Thu, Oct 1, 2015, at 03:48 PM, Kevin L. Mitchell wrote:
> > It looks like Pillow (pulled in by blockdiag, pulled in by
> > sphinxcontrib-seqdiag, in test-requirements.txt of nova and probably
> > others) had a 3.0.0 r
It looks like Pillow (pulled in by blockdiag, pulled in by
sphinxcontrib-seqdiag, in test-requirements.txt of nova and probably
others) had a 3.0.0 release today, and now the gate is breaking because
libjpeg isn't available in the image…thoughts on how best to address
this problem?
--
Ke
nge reads like an API change, requiring a
microversion bump. That said, I approve of increased consistency across
the API, and perhaps the behavior on limit=0 is something the API group
needs to discuss a guideline for?
--
Kevin L. Mitchell
Rackspace
to import more than one thing per line given the
rule to only import modules, not objects. While that is not currently
enforced by hacking, it is a strong style guideline. (Exceptions for
things like sqlalchemy do exist, of course.)
--
Kevin L.
only necessary to work around that
functionality being missing in Python 2.6, and has been deprecated as of
Python 2.7 because it's no longer necessary.
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing Lis
On Thu, 2015-07-30 at 15:27 -0700, Adam Lawson wrote:
> How many "up" votes are needed for code to be accepted into the trunk
> (assuming it passes testing etc)?
Which project? Different projects may have different criteria.
--
Kevin L. Mit
file to files.
I like that division based on subsection scheme; that seems perfect to
me.
--
Kevin L. Mitchell
Rackspace
signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing Li
ll become true of a single nova/flags.py if we go that route.
I do like Roman's idea of centralizing them into a smattering of files,
though. What if we were to create a new top-level package and split the
config options up into a small number of individual files there?
ake
it harder to maintain, such as ensuring the help text is updated when
the code is. If nova were a smaller code base, I think it would make
sense to reorganize in this fashion, but given how large nova actually
is…
--
Kevin L. Mitchell
Rackspace
___
On Mon, 2015-06-22 at 18:10 +0100, Daniel P. Berrange wrote:
> On Mon, Jun 22, 2015 at 11:10:40AM -0500, Kevin L. Mitchell wrote:
> > On Sat, 2015-06-20 at 21:35 +0100, Daniel P. Berrange wrote:
> > > In general I would say that is an unsupported deployment scenario to
> >
est on the hypervisor node…
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.o
ense as a possible solution? That at least would be a standard
HTTP convention for this sort of thing, and tends to match up with the
semantics of a changes-since query parameter.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25
--
Kevin L. Mitchell
quot;X-OpenStack-API-Version"?
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.opens
0 is capable of SSL? Usually,
people use port 8080 for plain old HTTP servers or proxies, and trying
to talk SSL to a plain HTTP proxy would probably result in that error.
(Also noticed that your proxy URL is specified as "http://";; if you know
that proxy works for SSL, try "https:/
f the https URL. You should be able to use
"git remote remove gerrit" and re-run the "git review -s" to get that
all fixed up. (Could also use "git remote set-url", FYI, but I figured
starting from scratch may be easier for you…)
--
Kevin L. Mitchell
Rackspace
ts mechanism to
dynamically generate an output file in the interim (as is done for
configuration now), which may improve the situation from Horizon's
standpoint, until the discoverability piece is in place.
--
Kevin L. Mitchell
Rackspace
ut below that is a "Toggle CI" button and
nothing else. Reloading the page has no effect, and the same behavior
applies to all nova reviews I've tried to load. Restarting by browser
did not have any effect.
--
Kevin L. Mitchell
Rackspace
_
and would presumably
also prohibit a body with GET and HEAD, so I'm -1 on this: we should
actively discourage service developers from requiring bodies on HTTP
methods that a client framework may prohibit sending bodies with.
--
Kevin L. Mitchell
Rackspace
___
se to me would be 413 ("Request Entity Too Large") and
403, the definition of which is wide enough to encompass the over-quota
condition; and of those, 403 makes the most sense. (Note that I believe
we use 413
ith comments, +1s, or objections within one week.
Definitely a +1 from me…
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?sub
run_tests.sh only as a legacy thing we can't fully get rid of quite yet.
(Incidentally, for my testing purposes, I don't care where it is, as
long as it's somewhere; so we could also move it to, say, "tools". I
don't even care what it outputs, as long as it gives a reasonable ret
h like a hot potato.
(Well, there's some other minor issue, having to do with odd characters
in path names, but I can just find a different way to encode the path
name to deal with that problem :)
--
Kevin L. Mitchell
Rackspace
_
i in the venv of your
> choice. You don't need run_tests.sh for that.
No dice. I don't want to have to parse the tox.ini directly. We're
talking about automated tests here, by the way.
--
Kevin L. Mitchell
Rackspace
___
We need this capability at present, so
we have to run tests using run_tests.sh instead of tox :( I have an
issue open on tox to address this need, but haven't seen any movement on
that; so until then, I have to oppose the removal of run_tests.sh…
despite how much *I'd* like to see it
l in Python 2, it just doesn't have the machinery
to really detect the mixing :)
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
there it is.
(I have it licensed under the GPL right now, but if anyone wants to use
it, I'd be happy to relicense under Apache…)
[1] https://pypi.python.org/pypi/policies
--
Kevin L. Mitchell
Rackspace
__
OpenStack
how many entries are in whatever array from which
the script selects randomly? That's the best part of the release
script, IMO :)
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for u
on clients to explicitly grab the attributes that they're
> looking for, but that doesn't seem too crazy and it would simplify adding new
> attributes on the server side. You'd still need versioning to h
re-review it based on whether votes to that point have been +'s or
-'s. I even subscribe to a couple of projects and check out new reviews
submitted there. This is actually partly to blame for me being such a
prolific reviewe
ear to have been abandoned; I just cleared several from the
novaclient review queue (or commented on them to see if they were still
alive). I also know of a few novaclient changes that are waiting for
corresponding nova changes before they can be merged. Could these be
introducing a skew factor
g that can easily be added to all OpenStack APIs, and
once that happens, then I can foresee it becoming a formal standard
recommended by the API WG…
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not
hink they should go in a repo separate
from any of our *-specs repos; to me, a spec provides documentation of a
change, and is thus independent of the guidelines.
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing
similar to the distinction between
4xx and 5xx errors in HTTP? ("You made an error" vs. "The server messed
up".) Is it intended to convey a retryable condition? ("If you retry
this, it may succeed.") If it's intended to convey that the server
mes
y some components like
nova-api have the capability to fork; but the other components that use
green threads are largely IO-bound, so threading based on IO call
blocking makes sense there.
[1] https://wiki.python.org/moin/GlobalInterpreterLock
--
Kevin
On Tue, 2015-01-27 at 14:41 -0800, Michael Still wrote:
> I would like to nominate Melanie Witt for the python-novaclient-core
> team.
I +1 this…
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing Lis
yword argument: "
"'session'"
)
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists
that we should encourage the first situation, where
all properties are included, even if their value is null.
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
http://logs.openstack.org/26/145626/2/check/gate-nova-python27/b350bbc/console.html
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstac
ot;
is the way to go, but I helped hash that out in the novaclient
implementation as a reviewer. I also had suggestions about how it
should be transmitted in the REST API, but that had already been settled
at the blueprint phase; that may be something the API WG will want to
take up and review
runs directly on the hypervisor…
but this is not necessarily the case for all virt drivers. For example,
the host for Xen-based installations is often a separate VM on the same
hypervisor, which would have its own distinct IP address.
--
Kevin L. Mitchell
Rackspace
___
service, which may be separate from the hypervisor. For instance, on
Xen-based setups, the host runs in a VM on the hypervisor. There has
also been discussion of allowing one host to be responsible for multiple
hypervisors, which would be useful for providers with large numbers of
hypervisors.
oximately one day, then
be automatically rolled back by the scheduler.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ouldn't be
expecting any relative imports (and should raise an error if there are
any). Still, that does show that some work needs to be done to the
simpler H306 test (probably involving changes to the core import
normalization)…
--
Kevin L. Mitchell
Rackspace
_
was referring to is H306, which isn't
all that complicated. It seems like the rest of the code is related to
the checks which I just agreed should be dropped :) Am I missing
anything?
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
k
we should keep the H301, H303, H304, and the basic ordering checks,
however; it doesn't seem to me that these would be that difficult to
implement or maintain.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
question for delete, also for other method.
>
> 2014-12-09 1:11 GMT+08:00 Kevin L. Mitchell :
> On Mon, 2014-12-08 at 14:07 +0800, Eli Qiao wrote:
> > I wonder if we can use body in delete, currently , there isn't any
> > case used in v2/v3 api.
>
On Mon, 2014-12-08 at 14:07 +0800, Eli Qiao wrote:
> I wonder if we can use body in delete, currently , there isn't any
> case used in v2/v3 api.
No, many frameworks raise an error if you try to include a body with a
DELETE request.
--
Kevin L. Mitchell
to
objects; one could even include a column to record who performed the
change. And of course I've suggested this as a DB table, but we could
also consider the merits of ditching the table and doing the same thing
as some sort of notification through the notifications system…
--
Kevi
to cover cases such as an LDAP backend? That
could be as simple as allowing a null value.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
service; from there, we can see whether it makes sense to roll it into
Keystone or maintain it as a separate thing.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-
g it for purposes outside of OpenStack…)
Just my $.02…
[1] https://wiki.openstack.org/wiki/Boson
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ing
anything. We may have *links* in the payloads, but those are provided
for convenience; anytime nova refers to a flavor, it returns the flavor
UUID.
I would, by the way, suggest using UUIDs rather than plain IDs, for
consistency with the rest of the APIs…
--
Kevin L. Mitchell
Rackspace
e been put forward with
3 days left in the nomination period, then the election coordinator
would send out the appropriate reminder email. I think this would have
the same effect as the one week re-open period without delaying the
election process.
--
e?
I missed the [oslo] tag in the subject line and was thinking generally;
so no, none of the Xen plugins use anything from oslo, because of the
need to support 2.4.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.o
alled :)
As for the clients, we could probably drop that segment now; it's not
like we *test* against 2.4, right? :)
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
On Wed, 2014-10-15 at 12:39 -0400, Andrew Laski wrote:
> On 10/15/2014 11:49 AM, Kevin L. Mitchell wrote:
> > Now that we have an API working group forming, I'd like to kick off some
> > discussion over one point I'd really like to see our APIs using (and
> > I
tion itself would be listed
on that operation. As a side effect, this would allow us (not require,
though) to queue up operations on a resource, and allow us to cancel an
operation that has not yet been started.
Thoughts?
--
Kevin L. Mitchell
Rackspace
___
On Tue, 2014-09-23 at 18:18 -0400, Jay Pipes wrote:
> Yes, I'd be willing to head up the working group... or at least
> participate in it.
I'll raise my hand to participate…
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailin
tps://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK
Well, openstacksdk is a client, and we're talking about a server. A
server, in this instance, has some advantages over a client, including
making it easier to create that client in the first place :)
--
Kevin L. Mitchell
Rackspace
ondering about is if we should create a
unified ReST API service to replace the service from all of the
individual projects. Then, users can just hit that one service to
handle all their different interactions.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-
the case here. Further,
there's no reason that _get_collection_kwargs() needs to use an
OrderedDict: it's initialized in an arbitrary order (generator
comprehension over a set), then later passed to functions with **, which
converts it to a plain old dict
—I have proposed a review[1] to replace it with a simple dict.
[1] https://review.openstack.org/#/c/123189/
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Thu, 2014-09-11 at 18:35 -0500, Ed Leafe wrote:
> On Sep 11, 2014, at 5:05 PM, Kevin L. Mitchell
> wrote:
>
> > I'd suggest trying:
> >
> >res = amodel.Assemblies(
> >uri=common.ASSEM_URI_STR % pecan.request.host_url,
>
pecan.request.host_url)
By moving the first argument to a line by itself, pep8 can be satisfied
by indenting the following lines by 4 spaces.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ut.side_effect = etimeout.Timeout()
I looked into that too, but the docs for Timeout indicate that it's an
Exception subclass, and passing it no args doesn't seem to start the
timer running. I think you have to explicitly pass a duration value for
Timeout to enable its timeout be
ve +A in
the hands of the existing cores? That way, their reviews can be counted
by the core reviewers. With this change in policy, you still need two
+2s, but you have more people that can +2, and you only need one of our
limited number of cores to
cluttered; we split functions when they get too big, we split modules
when they get too big, and we create subdirectories when packages get
too big, so why not split repos when they get too big?
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev m
possible. After all, I doubt anyone would seriously
suggest that we must always use something like the "_unset" sentinel,
even when None has no special meaning…
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
not be evaluated at
LOAD-TIME, which is what your original code does.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
1 - 100 of 138 matches
Mail list logo
