27;re right, nothing _should_ break. But
then the following is legal:
cinder create
What does that do?
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
These changes have been completed. Welcome Ian!
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ll pick someone based on the commits for that feature. That
specific bit might not scale to other projects, but I think documenting
some informal connectivity like this would be helpful.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailin
On Fri, Aug 15, 2014 at 4:31 PM, Jay Pipes wrote:
> current Tempest repository, into their own repo called
> "openstack-integration-tests" or "os-integration-tests".
>
I see what you did there...
+1 anyway
dt
that otherwise were not required for pure client
installations.
I don't know what your middleware dependencies are, but I think it would be
good to consider the effect that move would have on client-only
installations.
dt
--
Dean Troyer
dtro...@gmail.com
_
eason to not use the word 'incubator'. It also has the
connotations from Oslo of being 'copy-pasta' code.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
gh that making the logfile
names and locations more obvious in the gate results will be helpful.
I've started scratching out a plan to migrate to full names and will get it
into an Etherpad soon. Also simplifying the log file configuration vars
and locations.
dt
--
elf.
There might be room to optimize if we're capturing something that is also
being logged elsewhere, but when using screen people seem to want it all in
a window (see horizon and recent keystone windows) anyway.
dt
--
Dean Troyer
dtro...@gmail.com
_
own the wrong
path. This matters to be because I want to also leverage the existing
.gitignore files we have.
Just to join the party I pushed up the working state in
https://review.openstack.org/117772.
dt
--
Dean Troyer
dtro...@gmail.com
__
.gitignore and
.bashateifnore. ;)
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
be available
_during_ the discussion to pull it all together. I'll follow-up after some
Sunday afternoon right-brain processing while I'm at the park.
Film at eleven...
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mail
e .bashateignore to
both exclude as well as include the files to be processed using the
gitignore syntax.
Starting with the list of files in the repo is also an option, and
excluding from there...but I'm not going to have that tonight.
d
y what Mark also wrote about, when
that happens off-line, and I think it is our responsibility (those
advocating the reviews, and those responding to them) to note the outcome
of those discussions on the record somewhere, IMO preferably in Gerrit.
dt
--
Dean Troyer
dtro...@gmail.com
; your
mileage may vary; allow 4 to 6 weeks for delivery; any resemblance to
functional code, living or dead, is unintentional and purely coincidental;
representations of this code may be freely reused without the express
written consent of the Commissioner of the National Football League.
--
ssing should be an independent attribute that is
set on projects as a result of nomination by TC members or PTLs or existing
core members or whatever trusted group we choose. I'd say for starters
that anything from Stackforge that we use in integrated/incubated projects
is on the short list for th
out you'll need to dig further into the Nova log files
to see why no working compute node is available.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ud user that just want to get his VMs
running isn't going to be happy, especially on Windows.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Wed, Sep 17, 2014 at 3:53 PM, Robert Collins
wrote:
> On 18 September 2014 08:01, Dean Troyer wrote:
> > Interestingly enough, the distros are doing exactly what they don't want
> us
> > to do, ie, rebuilding things to use 'their' tested version of
> depen
that DevStack needs to set a default for most
services that are currently either too big (nproc) or too small (Keystone
at 1). Of course, moving things to mod_wsgi moots all of that, but it'll
be a while before everything moves.
dt
--
Dean Troyer
dtro...@gmail.com
__
pos. This should also be true
for user-facing tools. OpenStackClient already picks up installed plugins
with the proper entry points configured so everything doesn't need to be in
the primary repo to play along.
dt
--
Dean Troyer
dtro...@gmail.com
___
if I always learn a lot about my project
watching users bend it in ways I never imagined.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I followed Horizon's lead in OSC and removed the tern 'tenant' from
all user-visible parts, except for the compatability OS_TENAMT_{ID,NAME}
variables and --os-tenant-{id,name} options. Neither of those is documented
anywhere though. This includes commands for all OS APIs it suppor
iddleware.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ps://etherpad.openstack.org/p/MinimalCLI
>
I left some comments about how I would format the commands to be consistent
with OSC.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openst
they are.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019233.html
[2] https://wiki.openstack.org/wiki/Mailing_Lists#Future_Development
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http:/
> I don't follow how this new library would be different from
> python-tuskarclient. Unless I'm just misinterpreting what
> python-tuskarclient is meant to be, which may very well be true :).
This is essentially what I suggested above. It need not be a separate repo
or ins
PI bindings and
a this CLI on top of them. Some of the newer clients may not include a
CLI. By default I think most people mean the library API when referring to
clients without 'CLI'.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev
bits that
you want. Mixing them (ie, some Havana and some Icehouse) is not directly
supported, you'll have to do that by hand.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.op
-cloud/
> .
>
Actually, to do a stable/* release, check out that branch of DevStack, it
has the correct stable branch settings in stackrc already. But to do
milestones, you would want DevStack somewhat close (for example, current
DevStack master is still OK for the I-1 milestone) then set the
it a patch.
Prior art is a patent concept, not related to copyright. Copyright is
>
+1...this stuff gets confused too much these days...
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
With the new year comes a long-overdue cleanup to the devstack-core
membership and the desire to expand he team a bit. I propose to add
Chmouel Boudjnah as he has been a steady contributor for some time, doing
much of the Swift implementation.
dt
--
Dean Troyer
dtro...@gmail.com
libxslt-devel # dist:f20
There are some additional tweaks that I'll ask Flavio to add to
https://review.openstack.org/63647 as it needs at least one more patch set
anyway.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
Ope
l the end of the window. Setting
FORCE_PREREQ=1 in local.conf will turn off the whole mechanism.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ble options in
configuration has led us down the slippery slope of complexity that is
extremely hard to recover from.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Welcome to the DevStack core team Chmouel!
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
the
local.conf mechanism.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
l CLI parsers and decorators.
Does the long-term goals include a common caching layer?
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e resistance there is the chunked transfers they both
do.
I'm really curious what 'noauth' means against APIs that have few, if any,
calls that operate without a valid token.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailin
is the bottom of the cake and
eliminating duplication and accumulated cruft from repeated forking and
later direction changes.
The creamy gooey middle is the API-specific bits that right stay exactly
where they are (for now??) and can continue to ship a stand-alone cli if
they wish.
dt
--
layers
already present underneath the object-store commands as an experiment to
see how slim I could make then and still be usable. It isn't necessarily
what I want to ship everywhere, but the REST layer is eerily similar to
Jamie's in keystonec
why they didn't
get changed. I feel a bit braver now... :)
>
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
his sort, let's talk. You
may have noticed that few (any?) of the recent major API revs are
documented in this manner...
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ues are used? It seems like
a better default could be worked out here too; is 'localhost' ever the
right thing to advertise in a real-world deployment?
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.o
ings like tenant IDs in the SC. This has the same
issue as the auth URL in how to do this without instantly breaking the
existing clients.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
lready.
You should be able to just drop these files into an existing DevStack
checkout and go.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ne.conf. Discovery is really useless if
the URL you are given is https://localhost:5000/v2.0. Do we need to talk
about another horrible horrible hack to deal with these or are these
deployments going to be left out in the cold?
dt
--
Dean Troyer
dtro...@gmail.com
trib?
I don't mean to be picking on Cinder here, this seems to be recurring theme
in OpenStack. I think we benefit from strengthening the precedent that
makes it harder to get things in that are not ready even if the timing is
inconvenient
output is designed to be easily parsable, and with a bit of work I
think it could provide the info above and be logged with the rest of the
logfiles.
Thoughts?
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.ope
gt; the right answers are.
>
Thaks for helping. OpenStack is huge; I've got the benefit of having
learned it as it grew. We need this kind of input from fresh eyes to help
flush out the inconsistencies that I know I am blind to.
dt
Dean Troyer
dtro...@gmail.com
__
disposable VM is just asking for trouble in
a number of ways. Sean's local mounts via VBox and my remote git repos are
only two ways to operate in that environment, I'm sure there are many
others.
dt
--
Dean Troyer
dtro...@gmail.com
_
> needed system packages).
>
That bug is closed and against Grizzly, is that the one you meant to
reference? I added a note about INSTALL_TESTONLY_PACKAGES to the wiki page
above and it will be in the next rev of devstack.org.
dt
--
Dean Troyer
dtro...@gmail.com
___
ibs and their prereqs is bad
enough, adding to it is not tenable and is part of what is motivating the
SDK efforts.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
that Neutron was enabled -
> ENABLED_SERVICES
> had multiple "q-*" entries, but 'is_service_enabled neutron' was returning
> 0.
>
This is the correct return, 0 == success.
Can you point to a specific log example?
dt
--
Dean Troyer
dtro...@gmail.com
_
In this way the only tie between unit testing and
> DevStack is that they be done on the same machine. Maybe this is the way
> to go?
>
That is exactly what that variable is for. There are times we don't want
those packages installed and it is MUCH easier to add them than to remov
in API command sets in OSC also are
loaded in this manner even though they are in the OSC repo so they
represent additional examples of writing plugins.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
in
the entry point key=value pair. Everything else about them, including the
help text would be code changes.
It sounds like you may be wanting something parallel to OSC, ie, a
Tuskar-specific rebranding of it with a overlapping-but-different command
set.
dt
--
Dean Troyer
dtro...@gmail.com
far) backward-compatible in
that if is_neutron_enabled() is not declared (as is the case now) the old
check in is_service_enabled for 'neutron' should still catch it. That
happens everywhere else and in the DevStack test scripts, so I&#x
r stepchild many times.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
each compute host.
>
I don't understand this conclusion. in multi-node each node gets its own
specific ENABLED_SERVICES list, you can check that on each node to
determine how to configure that node. That is what I'm trying to explain
in that last paragraph above, maybe not too
/cgit/stackforge/python-congressclient/ is a
current example of a lib+plugin repo.
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
FWIW, I have done this with 'other' cloud
manager APIs, some that used Keystone auth and some that didn't. Either
way, if there are useful patterns, feel free to steal them...
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenSta
t -t nfs
> 10.XX.XX.XX:/nfsvol
> /mnt/state/var/lib/cinder/mnt/527dc3646de39dbda076e3a72dca54e5\nExit code:
> 32\nStdout: ''\nStderr: 'mount.nfs: Protocol not supported\\n'"}
>
Make sure you have everything installed for NFS support on your cinder
volume nodes and nova com
the cleanup and ongoing enforcement.
> So... the question is, is this worth it? It's going to have fall out in
> lesser used parts of the code where we don't catch things (like -o
> errexit did). However it should help flush out a class of bugs in the
> process.
>
This
tracking installed OS package dependencies and Python packages so it can
all be undone. But the above is a bug...
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
good thing. The DevStack defaults are chosen for developer
and CI testing use and do not necessarily take in to consideration any
actual deployment considerations.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.op
use here for one of them:
'system service' vs 'openstack service'.
One of the things multi-node adds is the distinction between the cluster
using a service and a specific node needing it configured or started.
Does this need to be solved before the plugin work can be
first
time we've had to do that when things change out from under us. But I hate
doing that to ourselves...
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
d the
> approach to API testing.
>
Testing recommendations haven't been part of the conversation yet, but I
think it is within scope for the WG to have some opinions on REST API
design and validation tools.
dt
--
, I prefer always
including null/empty properties here because it is slightly more
self-documenting. Having spent the morning chasing down attributes for an
API to be named at a later date by looking at server code, we do not help
ourselves or the users of our APIs by omitting this sort of thing.
reements on terminology or how certain resources might be
represented outside of the cloud; 'tenant' vs 'project' is a prime example.
The ambiguousness of the term 'user' is not helping. It means different
things to an SDK an
reset to the
branches in stackrc/local.conf.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
as a PyPI package and the
usual OpenStack tarballs.
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
this since then but do recall talk about being
able to either implement the required changes in upstream requests or
somehow hack it in from below.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.opensta
ince I've tested this and it is likely to need some
love. The basic structure, including building a root and intermediate CA to
issue certs that look like real-world certs, has been present for almost a
year and a half.
dt
--
Dean Troyer
dtro...@gmail.com
_
e active language-based teams). They all should consume the
output from a UX R&D effort, I guess I am open on the program structure to
make that work. Horizon is already a part of a program, OSC needs to be
and the SDKs will also need to be in the near future.
dt
--
Dean Troyer
dtro...@gma
riter and I am not. ;) I may steal that
list...
What you have listed fits with what I see happening as the Client Tools
adds the SDK projects (#1 and 2). #3, 5 and 6 are already goals for
OSC[1]; and #4 is what we are here talking about now.
[1] I expect OSC to switch to use the Python OpenStack SDK
anizationally, I see their future use diminishing
over time.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
it/stackforge/golang-client/<http://git.openstack.org/cgit/stackforge/golang-client/>
https://git.openstack.org/cgit/stackforge/openstack-cli-powershell/<http://git.openstack.org/cgit/stackforge/openstack-cli-powershell/>
dt
--
Dean Troyer
dtro...@gmail.com
__
esting short of gating
* 'thirdparty' - stuff that requires hardware or licensed software to fully
test
Also, contact information should be required for anything 'special' to at
least know who to notify if the thing is so broken that removal is
contemplated.
Projects
.com,n,z
Review history:
https://review.openstack.org/#/q/reviewer:dtroyer%2540gmail.com,n,z
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
you know
they will fail.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s to be a separate repo, similar to how
keystoneclient is a separate repo but still part of the Keystone project.
The primary problem being addressed is dependencies and packaging, not
governance.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
want to see Ceph support for Cinder, Glance,
Swift, etc in DevStack as I think it is cool and useful. But it is not
required to be in the DevStack repo to be useful.
Chmouel has proposed a session on this subject and it is likely to be
accepted as there are no other
find combing layers 1 and 2 more useful,
especially for organizational and other purposes.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
his isn't from OCL. Actually we'd have been
much farther down the road if we had used Termie's bits a year ago. Whether
that is a bug or a feature is left to the reader to decide.
Code speaks, sometimes, so I'm going back to writing some more client bits.
Someone come help.
pose where things can be
improved. And what we are doing right.
dt
[0] TODO: cut-n-paste in actual allegorical noun
[1] Yuck, better word here too!
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ould tremendously simplify using JSON Home from the client
standpoint as there should then be only one doc to cache and parse. And if
not that, at least getting all of the API versions in one round trip.
dt
--
Dean Troyer
dtro...@gmail.com
_
ith the option of
transforming both request and response for further 'live' API change
mockups.
I'm sure this has already been done, suggestions and pointers to existing
projects welcome. If not, suggestions for a good starting point/platform.
dt
--
me yet.
JSON Home seems flexible enough to be able to take on this role, I hope I
am reading the RFC correctly. I think the API docs mentioned earlier in
this thread is an appropriate place to hang these suggestions also.
dt
--
Dean Troyer
dtro...@gmail.com
__
On Tue, Sep 23, 2014 at 5:18 PM, Jay Pipes wrote:
> Yes, I'd be willing to head up the working group... or at least
> participate in it.
>
I'll bring an API consumer's perspective.
dt
--
Dean Troyer
dtro...@gmail.com
___
Op
wouldn't even need
to be in your project to block you from creating that clone instance if I
knew your UUID.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/ma
API_WORKERS in local.conf.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t, Ironic, Heat all either
playing alone or in groups, then the general admission seats in the tent.
This seems like a simpler model to govern, and to provide baseline guidance
in the testing relationships.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenS
e that many really are. But many is not all and the results are
clearly not acceptable because where we are having this conversation...
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists
I am Dean Troyer here to nominate myself as a candidate for the upcoming
Technical Committee election.
I have been involved with OpenStack for a long time, working on the
implementation at NASA of what became Nova. Since then I have been heavily
involved in a number of projects: I was an early
be variable, failed operations might actually need to
stick around longer.
Even as an operator with access to backend logging, pulling these state
transitions out should not be hard, and should be available to the resource
owner (project).
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/auth
cache is just another instance of that. I've been working under the
assumption for OSC that I'd be doing most of that work and that it would
live in OSC initially.
I like the idea of a cache object that the app subclasses and hands back to
the Session, then anything using the Sess
it readable by everyone and the literate-style formatting is to
help with that.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
k files being created, all wanting larger and larger
defaults, adding a fourth becomes Just One More Thing. If Nova's use of
LVM is similar enough to Cinder's (uses deterministic naming for the LVs)
I'm betting we could make it work.
dt
--
Dean Troyer
dtro...@gmail.com
1 - 100 of 396 matches
Mail list logo
