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
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
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
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
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,
>
l users could DOS Openstack !
I'm going to suggest that something like Turnstile[1] with
nova_limits[2] is the way to go here for ratelimiting.
[1] https://pypi.python.org/pypi/turnstile
[2] https://pypi.python.org/pypi/nova_limits
--
Kevin
rint on this. I'd be happy to take care of this.
Can you be a little more specific? In what context do you want to print
to stdout? That is, which client? (Servers should never print to
stdout; use the logging infrastructure for output.)
--
Kevin L. Mi
such an
attachment even if the review has already been merged?
Just something to think about :)
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ibrary
we use directly, rather than a repository we copy out of.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
otas should change to match. This could be done by manually updating
each quota that affects them, but a single change to a single attribute
makes better sense.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.opens
ith Emacs. I submitted the
change that eliminated that language from nova's HACKING at the time…
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t using 'unstable' as a component of the entrypoint group?
E.g., "nova.unstable.events"…
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t the entrypoint itself is unstable—nova
shouldn't care, it should just use it…
--
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-
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
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
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
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.
>
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
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
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
_
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
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.
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
___
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
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
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:
yword argument: "
"'session'"
)
--
Kevin L. Mitchell
Rackspace
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists
lly be printed, as
that could confuse users; no one expects a successfully executed script
to print a traceback, after all :)
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/c
here:
http://logs.openstack.org/68/96268/6/check/gate-python-novaclient-requirements/ea3cdf2/console.html
Anyone have any insights into this? I've seen the same thing happening
on nova.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev m
same error today. We may
have to consider a short-term pin to the version of setuptools (if
that's even possible) on projects that encounter the problem…
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack
and then deprecate these functions?
Um, all of the referenced files are already in oslo; that's what the
openstack/common subtree contains.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
r feature is
> being used and the impact of depreciation.
Exercising my penchant for precision: "depreciation" or "deprecation"?
I hope that the openstack code base isn't depreciating, even if parts of
it are being deprec
rtly because of lack of interest
from the rest of the community at the time. I'd say that, currently,
Boson is facing the chicken-and-egg problem—no one works on it because
no one is working on it.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-d
On Thu, 2014-04-03 at 10:54 -0700, Jay Pipes wrote:
> On Thu, 2014-04-03 at 12:13 -0500, Kevin L. Mitchell wrote:
> > On Thu, 2014-04-03 at 09:22 -0700, Jay Pipes wrote:
> > > Boson does indeed look interesting, but who is working on it, if anyone
> > > at this p
On Thu, 2014-04-03 at 19:16 +, Cazzolato, Sergio J wrote:
> Jay, thanks for taking ownership on this idea, we are really
> interested to contribute to this, so what do you think are the next
> steps to move on?
Perhaps a summit session on quota management would be in order?
--
that migration will end up taking…
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
the order of a couple of releases;
that would give plenty of time for the majority of the records to be
revisited and make the final migration run for a lot shorter time.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.
—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
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
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-
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
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
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 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
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
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
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.
--
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
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
;your first patch" bot and mentioned in the Gerrit workflow page.
That way, reviewers are using a consistent terminology—"femtonit" is
hardly standard English, after all; it's a specialty term we've invented
—and developers have guidance on what it means and what they shoul
you should have to go to the quotas API to get information
about quotas. I really dislike the fact that we have two different
sources for the same information, and the feature drift that's occurred
here is an excellent argument for my stance :)
--
Kevin L. Mitchell
Rackspace
__
he several reviews that no core dev looked
at in an entire month, but I have no solutions to suggest there,
unfortunately :(
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ave no solutions to suggest there,
> > unfortunately :(
>
> Patches of your own or patches of other folks?
Patches of other folks.
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
.
>
> Improving upgrades is high priority, and I feel it will help reduce
> the amount of downtime required when performing database migrations.
>
> So I am happy to sponsor this.
I will also sponsor this for an exception.
--
Kevin L. Mitchell
Rackspace
___
It may be worthwhile to add some sanity-checking to limit_check() and
reserve() that ensure that they only work with the correct resource
type(s), in order to prevent this sort of problem from occurring in the
future.
--
Kevin L. Mitchell
Rackspace
_
ed to do is give *-core permission to +2 the patches,
but only stable/maint team has *approval* permission. Then, the cores
can review the code, and stable/maint only has to verify applicability
to the stable branch…
--
Kevin L. Mitchell
Rackspace
On Wed, 2014-07-30 at 14:02 -0700, Michael Still wrote:
> I would like to nominate Jay Pipes for the nova-core team.
+1
--
Kevin L. Mitchell
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/
oo_opt
…
That ensures that arg will be the configured value, and should also
solve the import conflict.
--
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-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 wh
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
ation value at
_module load time_ rather than at run time. It is wrong for the same
reason that "def foo(arg={})" is wrong. If you fix the time at which
evaluation occurs, importing is no longer a problem.
> Is there any reason not to call register_opts()
> before importing other m
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
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
ybe keep it for ~6 months?
The thing here is, these environment variables have already been
deprecated for quite some time. The question is, have they been
deprecated long enough that we're clear to drop them entirely?
--
Kevin L. Mitchell
Rackspace
_
n I catch them in novaclient, but I figure if we
can remove the NOVA_* environment variables, we can probably also remove
those wholesale, and that should effectively discourage the
pattern-matching that causes developers to try to include them in the
first place :)
--
Kevin L. Mitch
gt;
> The current plan is to keep it and is what we have been doing so far
> when porting extensions, but there are pretty obvious long term
> development and test savings if we only have one API format to
> support.
I vote for dropping XML like a h
deliver a world class JSON API with
> validation and schema and comprehensive testing, than the current state
> of our JSON + XML approach which is poorly documented and only partially
> tested.
+1. Let's drop XML like a ho
ls. I'm
assuming that was to avoid a bottleneck, but Chris Behrens would be able
to say better exactly why this design choice was made. All I'm doing in
this discussion is trying to address one element of the current design;
I'm n
ing and reviewing in other areas, as well. Based on my
> experience with him I think he would be a good addition, so it would be
> great to have him on board to help keep up with the review load.
--
Kevin L. Mitchell
___
OpenStack-dev mai
ts. The other is to use the functions in
the "inspect" module to determine what convention the callback is
expecting.
--
Kevin L. Mitchell
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bi
methodology, and I like its features.
--
Kevin L. Mitchell
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
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
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
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
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
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
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
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
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
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
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
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
___
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?
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
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
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
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.
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
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
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
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 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
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
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
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
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
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
1 - 100 of 138 matches
Mail list logo
