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
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
--
Dean Troyer
dtro...@gmail.com
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
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
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.
dt
[0] except swift and glance, both of which were originally in the server
repo.
--
Dean Troyer
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
___
OpenStack-dev
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 robe...@robertcollins.net
wrote:
On 18 September 2014 08:01, Dean Troyer dtro...@gmail.com wrote:
Interestingly enough, the distros are doing exactly what they don't want
us
to do, ie, rebuilding things to use 'their' tested version
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
report, neutron net-create failed. You'll need to dig
through neutron logs to figure out why. I'd start with q-svc and q-agt
logs.
It is possible that this is a side-effect of an earlier error.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list
that 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
commands
* add initial support for global --timing option (similar to nova CLI)
* complete Python 3 compatibility
* add authentication via --os-trust-id for Identity v3
...and more...
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http
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.
--
Dean Troyer
dtro
choose. I'd say for starters
that anything from Stackforge that we use in integrated/incubated projects
is on the short list for that status, as it already has that implicitly by
our use.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
in dropping it if that decision is made.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin
, 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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
.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.
dt
--
Dean Troyer
dtro...@gmail.com
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
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
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
--
Dean Troyer
dtro...@gmail.com
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
___
OpenStack-dev mailing list
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
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
___
OpenStack
On Fri, Aug 15, 2014 at 4:31 PM, Jay Pipes jaypi...@gmail.com 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
Dean Troyer
dtro...@gmail.com
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 mailing list
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
. You'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
semver releases.
[1] Bad pun alert...or is there such a thing as a bad pun???
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
members Vish
Ishaya and Jesse Andrews, who between them were responsible for instigating
the whole 'build a stack script' back in the day.
Please respond in the usual manner, +1 or concerns.
Thanks
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev
Thanks for the feedback everyone, I've proposed the change in
https://review.openstack.org/112090.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
project itself.
dt
(soon-to-be-former?) DevStack PTL
--
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 Thu, Jul 10, 2014 at 10:19 AM, Gary Kotton gkot...@vmware.com wrote:
What about Kilimanjaro?
That'll get you sentenced to writing it on the chalkboard once for each
commit during the cycle...
dt
Dean Troyer
dtro...@gmail.com
___
Mailing list
to the nature of how we use screen, we are not going to
support two. Adding a third set of semantics to consider when debugging
process problems is not an option.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev
has certainly been a challenge for us
but at the moment we have about 90% of our issues with it solved. Changing
the devil we know for a bag of unknown is not appealing to me at this point.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing
.
The Python SDK is being built on a similar Session layer (without the
backeard compat bits).
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
levels to be more consistent with other
programs
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin
for anything 'special' to at
least know who to notify if the thing is so broken that removal is
contemplated.
Projects are going to do what they want regarding inclusion/exclusion
policies, I hope we can use common practices to implement those choices.
dt
--
Dean Troyer
dtro...@gmail.com
?
The nova client lib uses requests/urllib3 for HTTP, they do not support
SOCKS proxies out of the box. There have been some forks/patches to add
that to requests or urllib3, we have not tested those.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http
/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
___
OpenStack
the
output from a UX RD 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...@gmail.com
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 as it becomes
ready rather than attempt to salvage the existing client libs.
dt
--
Dean
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
into 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.openstack.org
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
___
OpenStack
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
; 'tenant' vs 'project' is a prime example.
The ambiguousness of the term 'user' is not helping. It means different
things to an SDK and a CLI and a webUI: an operator, a consumer, an app
developer and devops/sysadmin, and more.
dt
--
Dean Troyer
dtro...@gmail.com
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 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 submissions for the last slot.
dt
--
Dean Troyer
dtro...@gmail.com
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
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
OpenStack-dev@lists.openstack.org
http
://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
/ldap.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
to
determine how to configure that node. That is what I'm trying to explain
in that last paragraph above, maybe not too clearly.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
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
___
OpenStack-dev mailing list
OpenStack-dev
(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'm baffled
and awaiting the current gate check on 76867.
dt
--
Dean Troyer
dtro...@gmail.com
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
___
OpenStack-dev mailing list
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
___
OpenStack-dev mailing list
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
-
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
___
OpenStack-dev mailing list
. 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 remove
them.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing
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
http
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.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
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
___
OpenStack-dev mailing list
OpenStack-dev
://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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
strengthening the precedent that
makes it harder to get things in that are not ready even if the timing is
inconvenient. We're seeing this in project incubation and I think we all
benefit in the end.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev
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
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
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.openstack.org
http://lists.openstack.org/cgi-bin
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 mailing list
OpenStack-dev@lists.openstack.org
http
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
--
Dean Troyer
dtro
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 keystoneclient. There's why my bias...
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack
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
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
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
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
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 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
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
# 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
OpenStack-dev
are not from that image.
Restarting after a reboot is really outside what DevStack is intended to be
able to do. rejoin_stack.sh is only meant to restart the screen sessions
and nothing else. Even then it isn't perfect, which is why you should run
stack.sh again after rebooting.
dt
--
Dean Troyer
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
for the OpenStack 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
manually.
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
package, but the internal API should have its own
namespace/modules/whatever.
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
API 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 mailing
://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
during an upgrade, though.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo
://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.openstack.org/cgi-bin
that with the middleware.
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
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 supports.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
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
to DevStack
indicate a shortcoming in the plugin interface and may need to be
generalized anyway.
dt
[1]
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg08700.html
[2] http://ci.openstack.org/third_party.html
--
Dean Troyer
dtro...@gmail.com
is unmergable, even if it was based on a
semi-current commit.
FWIW, the opencontrail.org website appears to be off the air making it
harder to understand what it is you are trying to integrate here.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev
, over a year in the auth variable cases seems to be plenty long
to me.
Related but different are the now-long-undocumented option names with
underscores in them. I've noticed new undocumented ones get added from
time to time alongside the same option with dashes. ???
dt
--
Dean Troyer
dtro
embedded auth.
Please don't just copy one of the existing clients, down that path lies
madness.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
in Havana? Is it clear in the docs that this sort of situation
is coming in the next release or two? (And no, I haven't gone to look for
myself, maybe on the plane tomorrow...)
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev
of the new project activity is around new services/features.
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
modelines?
Who would be resistant to enforcing addition of modelines?
Who doesn't know or care what a modeline is?
For the record, I don't mind these things as long as they are at the end of
the file.
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack
301 - 400 of 416 matches
Mail list logo
