d files"?
Yes, in particular, files like AUTHORS and sample config files, which
IIRC are generated and included in tarballs.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage que
dows. That CLI doesn't exist yet,
and I do not see another reason (yet?) to include this in the initial
task list.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Un
his may,
however, help ease the concerns many have around static linking of
libs.
dt
[0] https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development
tack.org/p/golang-infra-work-plan
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.opensta
The odd week OpenStackClient meeting at 19:00 on Nov 24 is cancelled
due to the US holiday. We will see you all again on Dec 1 at 13:00
UTC in #openstack-meeting-3
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack
On Mon, Nov 21, 2016 at 9:05 AM, Csatari, Gergely (Nokia -
HU/Budapest) <gergely.csat...@nokia.com> wrote:
> Is there any way to configure allowed-address-pairs in osc?
These options are under review in
https://review.openstack.org/#/c/356219/ and should be merged soon.
dt
--
Dean Tr
of the 'community goals').
As you noted, this will not be easy for Swift or Glance (others?), but
if the impact to deployers can be quantified it makes it easier to
spend energy here.
dt
--
Dean Troyer
dtro...@gmail.com
___
alking about OpenStackClient and Shade,
not neutronclent. That bug is up to the Neutron team to decide.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Uns
m the users (varying from cloud
consumers to operators to OpenStack developers) has been regarding how
much they appreciate the command consistency. This is our biggest
feature.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenS
ng gRPC!
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.org/cgi-bin/mail
requires 'insider' knowledge of a
cloud deployment to use oaktree, ie it does not have to be deployed by
the cloud operator. You could run your own oaktree in front of
$PUBLIC_CLOUD and/or $PRIVATE_CLOUD.
dt
--
Dean Troyer
dtro...@gmail.com
oss multiple cloud deployments) this is no help
at all.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr
al from May) as a step to
get there without biting off the entire chunk at once. The infra
work, the community work, the packaging all is enough to handle at
once, this particular situation doesn't require oslo(-like) libraries
to gai
> and some vino.
I think most places call this pizza? :) At least Caputxes in el Born did ...
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : ope
tors
> as part of our team than not.
Please talk to the Neutron folk about this and their experiences over
the last couple of years. This is recent enough that it should be
very easy to recall the reasons for going in, as well as coming out of
the
nds so we can be more deliberate with the call orders and
also collision checking. There also needs to be some way to sanity
check that not just any old thing that you might not be aware of is
hooking your commands.
dt
--
Dean Troyer
dtro...@gmail.com
_
ith the clients
initialized as I showed above. Note that we currently can not reliably
hook existing commands to extend them, for example to support a 'server
create' that uses --ram, --vcpu and --disk in place of --flavor. That will
be discuss
etc), the question is if
this is a necessary/useful component of testing that upgrade path?
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
#/c/335141/
[2] https://etherpad.openstack.org/p/arch-wg-draft
[3] https://wiki.openstack.org/wiki/Meetings/Arch-WG
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
simpler.
I thank you and am honored by your support.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
into a front-page document
for the group, suitable for a repo docs tree or a wiki page, depending on
how we choose to move forward.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
alize a bit more, if the 'baremetal driver' has different kinds of
properties, or groups of properties that you want to distinguish, I would
suggest doing that with a common option name like you have above:
'--raid-logical-disk-property' and defining more of those as you need
them. But use the same approa
On Wed, Sep 7, 2016 at 10:19 AM, Dean Troyer <dtro...@gmail.com> wrote:
> I created the OSC session Etherpad[0] to start tracking these topic
> suggestions.
>
> [0]https://etherpad.openstack.org/p/osc-otaka-summit
>
/me sighs loudly
I wish I could blame the lack of caffein
release steward role extending, informally, until that
release's EOL. Maybe that should also be addressed, be it affirmative or
negative...
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not f
On Wed, Sep 7, 2016 at 9:48 AM, Steve Martinelli
wrote:
> There's been a bug filed against OSC to implement ospurge for cleaning up
> resources in (compute, network, storage, image and identity) [1] for a
> while now. As Jordan said, this is something we want to be
away or be an alias for USE_TLS. And
honestly, we should think about setting USE_TLS True by default anyway.
Eek, making DevStack more secure, who whoulda thunk it?
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Devel
//lists.openstack.org/pipermail/openstack-dev/2016-May/094841.html
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?sub
ouds use this term" or "it is the common way to
refer to this resource in the networking field" have been used in the past.
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing Lis
(depends on the upper-constaints change), to ensure your gate
won't break.
Thank you to the entire OSC team, we have had a lot of new contributors
this year, many of them working hard on the Networking commands.
dt
--
Dean Troyer
dtro...@gmail.com
be preferable to what I wrote a minute ago (using
qualifiying words) as this definition maintains separation for the
semantics of 'what can I do' vs 'what am I like'.
Plus 'trait' is a word that if/when surfaced into the UI will not collide
with anything else yet (that I know of). It is a lot like how
information about the host.
Also, if these terms get surfaces to the user-visible level, I would like
to see them fit existing usage as much as possible so we don't get another
version of the 'metadata' vs 'properties' debate.
dt
--
Dean Troyer
dtro...@gmail.com
___
alog is from KSA's AccessInfo class)
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
branches, of the sort 'don't do X, even if it seems like a
good idea, here is why it is not'. This is how I see our stance on Git
submodules for example.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing Li
ngs? It's a bit confusing if
> we should our users warnings that we can't fix.
>
This only happens in OSC trunk, which will be released as 3.0.0 soon. At
that point, osc-lib will also be released as 1.0 and be considered stable
and ready for general use.
dt
--
Dean Tro
are stable, it is
the clientmanager and shell parts that are still being developed.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@
bases talking to compute endpoints.
I'm not picking on you Sylvain, this is just something that I think needs
periodic reinforcement among our developer community.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mai
Golang will
be here (a special case, domain-specific, division of community (ask
Horizon devs)). And Bash, well, that isn't even a language.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List
surprise... surprise and fear... fear
and surprise... our two weapons are fear and surprise...and ruthless
efficiency...
It is left as an exercise to the reader to sort out who is who.
Congrats and thank you Morgan, I'll show myself out now...I see a chair
over there...
dt
--
Dean Tro
ra or Z core/time units of cloud resources. Wait, we do something
like that already? Maybe its time for a cost-of-living adjustment...
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (
s, down toward kernel-space and up toward end-user-space. We are
historically bad at leaving that sort of debt lying and cleaning can make
some strides toward reducing the community cost of maintaining the current
ecosystem.
dt
--
Dean Troyer
dtro...@gmail.com
___
lows. There are other reasons this
might be a bad idea, but I sense that you are losing traction fixating on
only this one.]
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
U
elp this process along, the config
option seems really clean to me. That leaves how to enable the users to
make use of that choice.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List
re Python
devs have (at least talked about) working in Go than in other newish
languages. There are worse choices to test the waters with.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usa
ng out those details is doable, even in a mostly-acceptable
manner.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.op
around a while... ;)
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.org
This is a reminder that the OSC even week team meetings have changed time
to Thursdays at 13:00 UTC in #openstack-meeting-3. See the eavesdrop
meeting page [0] for complete information.
dt
[0] http://eavesdrop.openstack.org/#OpenStackClient_Team_Meeting
--
Dean Troyer
dtro...@gmail.com
he additional
dependency of the new lib, adding it to the OSC repo would also work, I
just think it makes more sense for these commands to not be present in the
default installation non-cloud-ops users would see.
dt
--
Dean
On Wed, May 4, 2016 at 6:10 AM, Na Zhu <na...@cn.ibm.com> wrote:
> I found Dean Troyer set the *[Blueprint neutron-client] implement neutron
> commands*state to obsolete, does the OSC transition continue move along?
Other BPs are being used to track the specific work being perfor
a separate client/lib, it would make sense to do the
OSC plugin as part of that lib. That is also a chance to get a really
clean Python API that doesn't have the cruft of novaclient
dt
--
Dean Troyer
dtro...@gmail.com
__
the rest of DevStack. It should also
work with all of the major configurations, including Neutron L2, L3, DVR,
etc, and have a test job to exercise it.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mail
at using OpenStackClient with this (assuming
the service type is 'dashbaord'):
openstack catalog show dashboard
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : opens
On Wed, Apr 20, 2016 at 9:43 AM, Doug Hellmann
wrote:
> Cliff looks for commands on demand. If we modify it's command loader to
> support some "built in" commands, and then implement the commands in OSC
> that way, we can avoid scanning the real plugin system until we hit
t them the hard way.
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.org/
On Tue, Apr 19, 2016 at 9:06 AM, Adam Young wrote:
> I wonder how much of that is Token caching. In a typical CLI use patter,
> a new token is created each time a client is called, with no passing of a
> token between services. Using a session can greatly decrease the number
es? nova-net vs neutron, single- vs multi-node, etc.
Thanks for getting this started!
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
How does this sound? Tang, you specifically had E.4 mentioned, does
earlier on even weeks not work for you?
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscrib
alytics meaningless to
management-types is for it to go away, only to be replaced by some other
(possibly worse) metric to be misused.
We all need to educate our internal company leadership on the (lack of)
actual truth in those numbers...
..
The trick is to not get carried away with spec'ing every last detail.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.open
release, but we went ahead and implemented Network commands
using the SDK anyway because there were no compatibility issues. OSC
pre-dates the SDK by at least 2 years...
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenSta
On Tue, Apr 5, 2016 at 10:44 AM, Richard Theis <rth...@us.ibm.com> wrote:
> Here are my preferences:
>
> 1. even week: E.1 or E.4
> 2. odd week: O.3
>
I really don't want to go against the API-WG but want to keep it on
Thursday if possible:
E.4
O.3
Thanks for doing this
e "flavor" is a good
example, as it would (will someday soon) be named "server flavor". That is
also an example of it taking >3 years for a resource to need qualifying.
dt
>
--
--
Dean Troyer
dtro...@gmail.com
_
I am Dean Troyer and would like to nominate myself as a candidate for
re-election to the Technical Committee.
I have a bit of history with OpenStack: I was early contributor to
DevStack, I started Grenade to perform basic upgrade testing, and I started
the OpenStackClient project. I currently
important for OSC to be
consistent within itself than to be consistent with other projects.
REST APIs rarely make good user interfaces, otherwise we'd all use curl as
our CLI. They are also rarely designed to be end-user friendly.
dt
--
Dean Troyer
ents of name/ID fields and
rely on the REST API/server backend to handle problems there as required.
If you know of anything in OSC that does break due to empty name fields,
that is a bug and I'd love to know about it.
dt
--
nique in much of OpenStack. When ambiguity exists, we exit
with an error.
Also, this works to produce a volume with no name should you absolutely
require it:
openstack volume create --size 10 ""
dt
--
Dean Troyer
dtro...@gmail.com
___
on
> should be.
>
These sorts of things are getting extracted from my (and others') heads
into the devref docs. With the default logging settings we have no output
for delete commands unless an error has occurred.
dt
pping, versions.
>
The packages on https://trunk.rdoproject.org/ are built from master and
have version numbers in the future derived from the pbr default 'next'
version. So yes, there are packages distributed in the wild with version
numbers that have not been tagged.
dt
--
Dean Troyer
requests also includes its own CA bundle and
this is also changed to use the system CA bundle/certs by some packagers.
dt
--
Dean Troyer
dtro...@gmail.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstac
On Wed, Mar 9, 2016 at 11:26 AM, Doug Hellmann <d...@doughellmann.com>
wrote:
> openstack/os-client-config 1.16.0
> openstack/cliff 2.0.0
>
I believe these are good to go as-is.
dt
--
Dean Troyer
dt
o include a single rule to
do that? That's fine, I was concerned about a config/deploy option that
resulted in no visible change to detect...
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not f
ke it discoverable by the user/instance via
an API somewhere, even if just in metadata/config drive. We don't do this
now for far too many configuration settings (any?), this seems like a good
place to start.
dt
--
Dean Troyer
r to multiple non-free services?
I think with that stance on the tools we use it seems a bit disingenuous to
declare that one of our deliverables is a project to enable just that sort
of service. This does not strike me as cons
and welcome to the core team.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
elease, so what
> operations are supported keeps changing.
>
The point was more about the client/consumer of the API needing to do it
all at once, which seems to be the perception among the server projects.
If the new features had been incremental that might have been a different
outcome.
;).
If Identity had micro-versioned their way between V2 and v3 would the other
projects been able to convert faster due to not having to do it all at once?
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development
turn by holding back
contributions. And this may be the one place where the 'viral' nature of
the GPL would have been useful to us in a business relationship. [[NO I do
not intend to open that can'o'worms, only to illustrate our lack of that
built-in mechanism to lessen the impact of open core]]
sure to make sure the docs are up to snuff for each
specific API bump.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@li
ueue. And
now in a plugin world, it'll be a bit harder to maintain compatibility.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
without the commercial component(s) (at this time).
So while Poppy may not fully qualify for the open core label, it still
fails some of the tests that we want to see, such as a usable open source
implementation.
dt
--
Dean Tr
s we all agree it really is not a production-grade
implementation. That is an easy example, but as a community we have
crossed this bridge multiple times already and will be able to do it again.
dt
--
Dean Troyer
dtro...@gmail.com
__
O
ere is a long-standing disagreement on whether OpenStack APIs can/should
stand on their own, or simply be defined as 'whatever project Foo
implements'. We already have seen independent implementations of OpenStack
APIs, although not (yet?) as OpenStack projects. Duplication is already
happening in th
le architecture, specifically so that
out-of-tree components can be accommodated for whatever reason. The
projects play the role of arbitrator of namespaces in the case of many
back-end drivers. Having someone do this for OpenStack as a whole is a
necessary part of having a community-wide
On Thu, Feb 4, 2016 at 12:21 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> Nevermind--it's still there. Perhaps I need glasses (or afternoon
> coffee).
>
Nah, the fastest way to find something like that is to send a note to a
public mail list. :)
dt
--
Dean Troyer
dt
and is how the service
catalog has and will always work.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc
striving for consistency across
OpenStack. However, that is more of a matter of form and structure, not of
implementation and back-end structure.
I would hate to see us keep duplicating user-facing stuff for the sake of
back-end developer convenience.
dt
--
Dean Troyer
dtro...@gmail.com
_
ve had a couple of times in the
past when PrettyTable changes broke us unexpectedly. The recent stability
is encouraging.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubsc
>>
>>
> So far it looks close to zero emails :) PythonSDK is the only one that's
> in the OpenStack namespace I can see at quick search.
I think they do, the Python SDK is intended for application and user-facing
use, that fits
(when it becomes
official) but it is intended for downstream consumers, app devs mostly
rather than end-users and operators.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage que
ole space of a more usable API for users.
>
As part of another project crashing in -sdks I am fine with this. ;) I
like the idea of some consolidation, ever since Keystone left -dev it's
been REALLY quite there too.
dt
-
tal state' is meaningful
to a user that might be OK. But what thing has that state? A node? I
don't know what 'provision state' also refers to, a node? a port?
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Developmen
er, I'd like to forget whether my server is
a bare metal box or not and just use the same commands to manage it.
Also, I'd LOVE to avoid using 'boot' at all just to get away from the nova
command's use of it.
dt
--
Dean Troyer
dtro...@gmail.com
sue I see (so far) would be if there is a conflict and a
breaking change needs to be made.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-req
esources ('message flavor' is
the only one I recall ATM) have another word added that acts as a type
specifier, not a blind namespace prefix.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not f
(yet) so I know this is possible.
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.org/
rvice catalog? etc) then we should consider merging the commands.
(Disclaimer: for things in the OSC repo this works (see limits, quota) but
it has not been satisfactorily solved for plugins. If we need it we'll
move up its priority.)
dt
--
Dean Troyer
dtro...@gmail.com
__
ynchronize the integrational aspects of
> the openstack client project, going forward."
>
We do keep track of the resources being used by plugins in the OSC docs as
a best-effort central coordination. This is strictly opt-in as
ve different needs. It sounds like you
have been able to avoid that so far though...
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
hard' category for me and
I'll forget the current screen in a month and life will go on.
Thanks for keeping us up to date guys!
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not fo
uirements files for the
> clients.
For OpenStackClient: https://review.openstack.org/234406
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
itching
to keystoneauth1).
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.openstac
101 - 200 of 416 matches
Mail list logo