Re: [openstack-dev] Golang technical requirements

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

Re: [openstack-dev] Golang technical requirements

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

Re: [openstack-dev] Golang technical requirements

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

[openstack-dev] Golang technical requirements

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

[openstack-dev] [OpenStackClient] Weekly IRC meeting cancelled

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

Re: [openstack-dev] [osc]: Support for allowed-address-pairs in osc?

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

Re: [openstack-dev] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

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 ___

Re: [openstack-dev] [neutron][osc] Openstack client, Openstack SDK and neutronclient consistency

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

Re: [openstack-dev] [neutron][osc] Openstack client, Openstack SDK and neutronclient consistency

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

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

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

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

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

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

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

Re: [Openstack] Barcelona Food recommendations

> 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

Re: [openstack-dev] [ironic] When should a project be under Ironic's governance?

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

Re: [openstack-dev] [osc] bug/design flaw: Clients not cached per region

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 _

Re: [openstack-dev] [osc] bug/design flaw: Clients not cached per region

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

Re: [openstack-dev] [nova] Future of turbo-hipster CI

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

[openstack-dev] [architecture] Architecture WG Process

#/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:

[openstack-dev] [OSC][PTL] PTL candidacy for OpenStackClient

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

Re: [openstack-dev] [architecture] First meeting happened -- Regularly scheduled Thursdays at 1900

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)

Re: [openstack-dev] [ironic] openstack/python-ironicclient

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

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

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

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

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

Re: [openstack-dev] [devstack] on stud replacement for tls-proxy option on Ubuntu Xenial

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

Re: [openstack-dev] [ironic][OpenStackClient] deprecated commands (was Re: Upcoming OpenStackClient 3.0 Release (Monday))

//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

Re: [openstack-dev] [ironic][OpenStackClient] two openstack commands for the same operation?

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

[openstack-dev] Upcoming OpenStackClient 3.0 Release (Monday)

(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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

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

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

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 ___

Re: [openstack-dev] [nova] Thoughts on testing novaclient functional with neutron

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

Re: [openstack-dev] using feature branches, Swift's experiences

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

Re: [openstack-dev] [mistral][osc-lib][openstackclient] is it too early for orc-lib?

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

Re: [openstack-dev] [mistral][osc-lib][openstackclient] is it too early for orc-lib?

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...@

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

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

Re: [openstack-dev] [security] VMT addition

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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

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 (

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

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 ___

Re: [openstack-dev] [tc] supporting Go

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

Re: [openstack-dev] disabling deprecated APIs by config?

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: [openstack-dev] [tc] supporting Go

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

Re: [openstack-dev] [tc] supporting Go

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

Re: [openstack-dev] [keystone][api][v3]

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

[openstack-dev] [OpenStackClient] Meeting change reminder

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

Re: [openstack-dev] [nova][osc] Use of openstack client for admin commands

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

Re: [openstack-dev] [neutron] OSC transition

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

Re: [openstack-dev] [nova][osc] Use of openstack client for admin commands

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 __

Re: [openstack-dev] [devstack] - suggested development workflow without ./rejoin-stack.sh ?

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

Re: [Openstack] Get URL for Horizon from CLI?

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

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

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

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

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/

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

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

Re: [openstack-dev] [all] [devstack] Adding example "local.conf" files for testing?

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

Re: [openstack-dev] [osc] Meeting time preferences for OSC team

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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

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...

Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

.. 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

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

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

Re: [openstack-dev] [osc] Meeting time preferences for OSC team

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

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

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 _

[openstack-dev] [TC] TC Candidacy

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

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

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

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

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 --

Re: [openstack-dev] [cinder][openstackclient] Required name option for volumes, snapshots and backups

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 ___

Re: [openstack-dev] [nova][novaclient] Responses for Deletion Events

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

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

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

Re: [Openstack] SSL cert issue on openstack client

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

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

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

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

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

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

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

[openstack-dev] [OpenStackClient] New core team members

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

Re: [openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

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.

Re: [openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

;). 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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

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]]

Re: [openstack-dev] [Nova] Should we signal backwards incompatible changes in microversions?

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

Re: [openstack-dev] [all] tenant vs. project

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

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

Re: [openstack-dev] [all] the trouble with names

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

Re: [openstack-dev] [all] the trouble with names

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

Re: [openstack-dev] [infra] openstack/requirements repo has a stable/icehouse branch...

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

Re: [openstack-dev] [api] service type vs. project name for use in headers

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

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

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 _

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

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

Re: [openstack-dev] OpenStack-Announce List

>> >> > 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

Re: [openstack-dev] OpenStack-Announce List

(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

Re: [openstack-dev] [api] consolidate IRC change with #openstack-sdk?

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 -

Re: [openstack-dev] [Ironic] Quick poll: OpenStackClient command for provision action

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

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

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

Re: [openstack-dev] [Ironic] Quick poll: OpenStackClient command for provision action

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

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

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

Re: [openstack-dev] [oslo] Graduate apiclient library

(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/

Re: [openstack-dev] [Ironic] [OSC] Quick poll: OpenStackClient command for provision action

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 __

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

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

Re: [openstack-dev] [heat] Shared code between server and client

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

Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11

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

Re: [openstack-dev] getting rid of tablib completely (Requests + urllib3 + distro packages)

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:

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

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

<    1   2   3   4   5   >