s time but it would be good
to have this sorted.
Thanks
dt
--
Dean Troyer
dtro...@gmail.com
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
verify you have a good install of openstacksdk that matches
your python-openstackclient.
I have the following versions installed and working:
openstacksdk==0.19.0
python-openstackclient==3.17.0
dt
--
Dean Troyer
dtro...@gmail.com
___
Mai
a big chunk of my reservations about
being able to maintain consistency and user experience in a fully
split-OSC world.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage
ne...although wheels were just becoming a
thing when I last tried to bundle OSC into a py2exe-style thing so the
pains of things like OpenSSL may be fewer now.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Developm
o. Dang, did I just deconstruct my project?
One thing I don't like about that is we just replace N client libs
with N (or more) plugins now and the number of things a user must
install doesn't go down. I would like to hear from anyone who deals
wi
n cloud deployments, to
correctly handle when admin/policy refuses to do something and let the
user sort it out as necessary.
[0]
https://docs.openstack.org/python-openstackclient/latest/contributor/plugins.html#adoption
[1]
https://docs.openstack.org/python-openstackclient/latest/cli/commands.h
f reports from some of our StarlingX
contributors that access to Freenode IRC works from our (Intel) sites
but not from home. I am not going to speculate as to the cause, it
clearly is not open access, but also not totally closed off.
dt
--
Dean Troyer
dtro...@
On Fri, Aug 10, 2018 at 7:06 AM, Monty Taylor wrote:
> I'd like to propose removing Brian Curtin, Clint Byrum, David Simard, and
> Ricardo Cruz.
>
> Thoughts/concerns?
Reluctant +1, thanks guys for all the hard work!
dt
--
Dean Troyer
dtro.
this case OS_AUTH_URL. Check all of your auth configuration for
the client.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe :
it those bits could easily go somewhere in osc or osc-lib if you
don't also need them elsewhere.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-d
it those bits could easily go somewhere in osc or osc-lib if you
don't also need them elsewhere.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-d
d.openstack.org/p/osc-included_image_signing
[1] https://storyboard.openstack.org/?#!/story/2002128
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
onty has taken it to a
place where that should now be a possibility. I am willing to find
out that doing so is a good idea. :)
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage question
authentication logic, that was long ago pulled out of the keystone
client package.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
ort of thing all along: "don't
fork". Many have had to learn that lesson the hard way. This is
another opportunity to show _why_ it can be a bad idea.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Developme
for being quick on the conclusions there.
Even after some discussions yesterday it is not clear to me exactly
the right phrasing. I understand that the intention is to become an
incubated edge project, I do not know at what point StarlingX nor
Airship exactly
StarlingX, IMHO.
In the beginning at least it will be. We have prioritized lists for
where we want to start. Once I get the list and commits cleaned up
everyone can look at them and weigh in on our starting point.
dt
--
Dean Troyer
dt
not be widely useful. We need to
figure out how to handle those in the long term.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.op
the stuff that has
been cleared and released. Understanding (some) business decisions
are not one of my strengths.
I will say that my opinion from working with WRS for a few months is
they do truly want to form a community around StarlingX and will be
moving their ongoing Titanium development t
s not on the table, there
is a lot of work to digest before we could even consider that. Is
that the official capacity you are talking about?
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not f
] Honestly I don't think that hosting a repo of patches to OpenStack
projects is any different than hosting the repo itself. Also, anyone
remember Qmail? :)
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List
.0 we may have to play catch-up and maintain multiple
SDK release compatibilities (which has happened at least twice).
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions
to take on that task, you will have my support and
as much help as I am able to give.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
loating_ip
(etc) and subclassing network.common.NetworkAndComputeCommand to
leverage that work.
dt
[0] I can't take credit for this, rtheis, amotoki and others worked
this out very nicely.
--
Dean Troyer
dtro...@gmail.com
_
Keeping service
assumptions out of client-side stuff is the biggest reason OSC NEEDS
to get changed over to the SDK, like, 2 years ago. Then I'll not give
a rats ass about the legacy python client libs.
dt
--
Dean Troyer
dtro...@gmail.com
_
iends are on the hook to
maintain the compatibility and their patches are (mostly?) accepted.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.
f this was last week
regarding "MTU" in Network commands.
These are not hard rules, but strong guidelines that can and should be
interpreted in the context that they will be applied. And in the end,
the result should be one that is
t DNS should also be
using something to qualify it. The use of --zone in the Compute
commands pre-dates the existence of Designate by at least a coupe of
years. Also, the Network commands use "--dns-*" to refer to anything
specifically DNS related, so for consistency, "--dns-zone"
possible
> have all commands using one syntax?
This is the sort of thing that should be addressed in the long-overdue
OSC 4 release where we will make small breaking changes like this.
Of course, the old option will be properly deprecated and silently
supported for so
On Thu, Dec 21, 2017 at 11:11 AM, <d.l...@surrey.ac.uk> wrote:
> Can you point me to any documentation to allow me to build to this kind of
> layout?
I'm afraid I do not have any good pointers for that sort of network
setup, thus far my needs have been simple in that dept.
dt
--
iables and the documented Neutron
configs.
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
s (mostly) only a
problem the three largest and tightly-coupled projects? In the
current environment I do not see any of our corporate sponsors
stepping up to un-couple those three, but for the rest it seems like
Doug's suggestion goes a long way toward addressing problems being
brought up here.
ut explicitly specifying an image to give me the same
thing it did on the initial build. I suppose it would depend if
shelve/unshelve is supposed to me transparent like Andrew mentioned.
I would assume it would be without reading differently.
dt
--
Dean
On Thu, Nov 30, 2017 at 8:00 AM, Monty Taylor <mord...@inaugust.com> wrote:
> So let's add them to the core team, yeah?
+1
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not
specific
about the repo and branch to check out for each project and many
sub-projects and libraries. Also, the GIT_BASE variable may be
sufficient to point at your own collection of repos.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing l
ying
to SYD tomorrow), feel free to take it over if you want to finish it
up before then.
dt
[0] https://review.openstack.org/#/c/515209/
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for u
grandfathered-in pricing by being forced
to recreate I amy be unhappy.
> Sylvain's spec in #1 above, maybe we don't have this problem going forward
> since you couldn't remove/delete an AZ when there are even shelved offloaded
> instances still tied to it.
As a user I proba
of these proposals!
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.o
h better with your contributions and
OpenStackClient would not have gotten as far as it has without them.
Thank You.
dt
/me looking for one more post-Summit beer-debrief in the hotel lobby
next month...
--
Dean Troyer
dtro...@gmail.com
__
[followup...]
On Sat, Sep 9, 2017 at 4:51 PM, Dean Troyer <dtro...@gmail.com> wrote:
> [0] https://review.openstack.org/#/c/485232
I rebased this one to see where we stand with just removing the
'volume' service type.
dt
--
Dean Troyer
dtro...@
/#/c/485232
[1] https://review.openstack.org/#/c/453320 (abandoned)
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?sub
ata definitions
> service so that we all stay on the same page better.
This is a great example of why attributes that are actually used
elsewhere should be defined in the API rather than just picked out of
a collection of metadata/properties.
dt
--
Dean Troyer
stackclient' package has not been released yet, the current
plan is to make its first release when OSC 4 (next major release) is
released.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usag
r if deployments using CD are (or
have now) fallen behind similarly to what we know to be the case with
deployments on releases, only maybe not quite as far?
dt
[0]
https://devops.com/automic-empowers-cloud-continuous-delivery-openstack-integration/
--
Dean
evel REST API layers
into a stand-alone piece that shade, SDK and OSC can all benefit from
would be our best course, but then I have been wrong about this
layering thing in the past, so I throw it out there to have something
that can be used to push against to get what everyone else seems to
want.
would speed up the migration.
If I find a doc that tells me how to set up a VM with a Neutron
network and ports and subnets and floating IPs that uses curl, I'm not
reading farther.
dt
--
Dean Troyer
dtro...@gmail.com
__
O
id than I
would like today. Will be there if possible.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
at matter)
to have survived this long, but they have mostly because they were/are
just barely good enough that nobody wants to fund replacing them.
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not f
was before. If we want to go that
> route I'm happy to do so.
I would keep the output fields the same. If --minimal used to show
empty fields because the lookup was skipped, it would be OK to now
populate those, but I wouldn't add them just because you have the data
now without the lookup.
dt
-
ffects that ttx talks about, and is the setting
for another example of where we should be careful with documentation
and 'officialness' around projects that disappear, lest we repeat the
experiences with PostgreSQL and have deployers make choices based on
our docs that do not reflect reality.
dt
--
De
t is effectively never going to happen. We've seen how far
single-vendor projects have gone, and none of them reached that level.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage
ould have a common process model to follow, and any choice to
deviate from that is their own.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ.
ot sure that the actual repo is the issue, are we having problems
getting reviews to approve these? I don't see this but I'm also not
tracking the time to takes for them to get approved.
I believe it is just going to have to be a social thing that we need
to continue to push forward.
dt
--
ifferent ones that are actually more efficient in the long run.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
ept flavor
and image names when the non-unique names _do_ identify a single
result). Having that control lets me give the user more options in
handling edge cases.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Devel
know.
Now the question of how to actually do this? If we had some
side-channel to return results metadata then this config change would
be discoverable after-the-fact, which in this case would be acceptable
as the condition checking happens after (at least some of) results are
returned anyway.
d
g low-level REST layer that they then compose and wish I had
been more persistent then.]
[0] https://github.com/jaypipes/enamel
[1] http://git.openstack.org/cgit/openstack/oaktree
--
Dean Troyer
dtro...@gmail.com
__
Ope
necessarily having it approved.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.ope
ss of such a feature).
dt
P.S. I used 'tc-member' to catch both singular and plural forms.
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-
where.
I would really like to not add a new channel and do like the increased
traffic in -dev as of the last few months, but right now I think -tc
may be warranted.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development
ng next week is soon enough to extend Netwon's
EOL date, but starting in August most certainly is too late. (Newton
is our first realistic opportunity based on the LTS status of the
current testing configurations.)
Oh, and the number zero task is to make sure our stable team PTL can
stay for
bugging them for these things too, and not just "enterprise
ready" or "telco ready" or "GPU ready" or whatever their particular
shiny thing is this year.
Make long term releases important on corporate bottom lines and it
WILL become a thing.
dt
--
Dean Troyer
dtr
penStack consumers. Lets help them help themselves.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc
plugins get loaded that
differ between Shade and OSC's usage. once we complete resolving that
the level of reuse should be able to go up substantially.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Maili
uly useful, such as manipulation of the global
options, maintaining multiple client contexts, etc.
Thanks for sharing!
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to
uly useful, such as manipulation of the global
options, maintaining multiple client contexts, etc.
Thanks for sharing!
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
/#OpenStackClient_Team_Meeting
[1]
https://docs.openstack.org/developer/python-openstackclient/backwards-incompatible.html#release-3-10
[2]
https://docs.openstack.org/releasenotes/python-openstackclient/unreleased.html#id1
--
Dean Troyer
dtro...@gmail.com
The point is taken however, and I do
believe you are right Rocky that is something we should get more
proactive with regards to our neighboring communities.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailin
On Fri, Apr 14, 2017 at 9:50 AM, Dean Troyer <dtro...@gmail.com> wrote:
> [0] https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
> [1]
> https://governance.openstack.org/tc/reference/principles.html#one-openstack
Rats, I missed the UC char
service
contracts or chips along the way, our sponsors are happy too.
dt
[0] https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
[1] https://governance.openstack.org/tc/reference/principles.html#one-openstack
--
Dean Troyer
dtro...@gmail.com
_
pread out TZ-wise) to ensure some
planning is possible.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscri
monly known only by their abbreviation, and this usage
is in fact expected by users. In the end, picking commands that are what
users would expect to search for is what they appreciate the most.
dt
--
Dean Troyer
dtro...@gmail.com
___
erns over
world-wide participation
(I read ahead) Dims mentions personal conversations with some backing
away from running for the TC due to the meeting time, I wonder how
much language has been a factor for others?
dt
--
Dean Troyer
dt
. But you might be unhappy about the removal of py27
from distros just yet, as not all of OpenStack is py3 ready. We
should just upgrade all that code...
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Maili
as I say that I'll get reminded about something. :)
--
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-bi
adjust to our current realities.
I was excited to see the TC vision proposal released for general
comment and think this is a great opportunity to come together on
goals and ideals for our future. Please read it if you have not
already! https://review.openstack.org/#/c/453262
dt
--
Dean Tro
t one foot in both worlds. There are other similar uses.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
ing
IPs, etc). novaclient 7.1.0 will still work fine.
In general you will want to use the current clients whenever possible.
We work very hard to remain backward compatible so users are not
required to match clients to the cloud release.
dt
--
Dean Troyer
dtro.
I am Dean Troyer and would like to nominate myself as a candidate for
re-election to the Technical Committee.
I have been around OpenStack for a long time, primarily working on
DevStack, Grenade and OpenStackClient.
OpenStack has been going through the maturation process in the last
year or two
but the current names will probably never
change, we'll just have the qualified names for those who prefer to
use them.
Flavor is my favorite example of this as we add network flavor, and
others. It also illustrates the 'it isn't a namespace' as it will
become 'server flavor' rather than 'compute fl
On Mon, Mar 20, 2017 at 4:36 PM, Adrian Otto <adrian.o...@rackspace.com> wrote:
> So, to be clear, this would result in the following command for what we
> currently use “magnum cluster create” for:
>
> openstack coe cluster create …
>
> Is this right?
Yes.
d
ase, and in fact no dash here, resource names have spaces in them.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?
On Fri, Mar 17, 2017 at 8:20 AM, Saverio Proto <saverio.pr...@switch.ch> wrote:
> Is LBaaS even going to be implemented in the unified openstack client ?
No, it will be implemented as a separate OSC plugin. This is true for
all of Neutron's "advanced services" projects.
d
infrastructure.
There are a bunch of deployment projects that are also designed
specifically to run services with minimal base requirements.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for
me_. Others have
also shared a similar sentiment, including the tools they use to
achieve that result. I fully expect that there is a significant
number of people for whom the current situation is not working well
_for them_, and some of those folk were in that room.
ouple of descriptions of who this proposal is not
intended to address, who exactly is expected to benefit from more
mailing lists?
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage q
unately this is (was??) required for
libvirt live migration to work so is likely to not be an edge case in
deployments.
The safest read-back approach would be to generate both ISO9660 and
VFAT (if configured) and only read back from the ISO version. But
yuck, two config drive images...still better th
of config
drive in ways that none of us have imagined.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
f
those decision are made for us by those member companies promoting
their own priorities (your example of Ansible contributions is one).
But as a community we have an opportunity to express our desires and
potentially influence those decisions.
dt
--
Dean Troyer
dtro...@gmail.com
__
seamlessly, no lying
about the name like the browser User-Agent header nonsense.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
plugin configuration, which is by no
means authoritative.
There was a beginning of a service catalog type registry [3] that has
not gone beyond an initial proposal. Sean Dague recently revived this
and I believe it will be discussed next week at the PTG.
dt
[3] https://git.openstack.org/cgit/openstack/service
gle
OpenStack fit all sizes and types of deployments. I'll leave that for
$SUMMIT_COLD_BEVERAGE conversations for now.]]
dt
[0] Am I the only one who simply can not read 'LCOO' as anything other
than 'loco'? :)
--
Dean Troyer
dtro...@gmail.com
___
ntend,
I can see the entire set of notes by walking the stable release pages
now.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.o
lume of commits or notes that many projects have...
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:u
On Fri, Jan 20, 2017 at 10:46 AM, Dean Troyer <dtro...@gmail.com> wrote:
> I've proposed a couple of unit tests that appear to me to illustrate
> what OSC's functional test found. [0] runs on top of the revert, so
> this is the 'before' check, and [1] runs with the community
onal test found. [0] runs on top of the revert, so
this is the 'before' check, and [1] runs with the community image
change and should show the v1 breakage. As is often heard, "it's
working for me that way in DevStack" :)
dt
[0] https://review.openstack.org/423344
[1] https://review.
tack/glance/commit/265659e8c34865331568b069fdb27ea272df4eaa
I've posted a revert of 265659e8c34865331568b069fdb27ea272df4eaa due
to the breakage of API v1 this late in the cycle.
A couple of attempts on my part to see why the Glance unit tests did
not catch this have fallen short due to ENO_CAFFIE
discussion. Please chime in if interested,
> and/or make your interest known to scottda, mordred, or edleafe.
IIRC there may be some cross-project rooms available, but I can also
offer time/space in the OpenStackClient room for this discussion if
needed.
dt
--
D
ed as 'volume backup'. We could possibly
also do this with 'object' and 'container' from Swift, we will be
doing this with other resources (flavor -> server flavor comes to
mind).
Backward compatibility is very important to us though, so
has
at least two specific and distinct meanings in OpenStack to only add
confusion for yet another use at all.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: o
1 - 100 of 416 matches
Mail list logo
