Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series

2018-09-27 Thread Dean Troyer
On Thu, Sep 27, 2018 at 9:10 AM, Doug Hellmann  wrote:
> Monty Taylor  writes:
>> Main difference is making sure these new deconstructed plugin teams
>> understand the client support lifecycle - which is that we don't drop
>> support for old versions of services in OSC (or SDK). It's a shift from
>> the support lifecycle and POV of python-*client, but it's important and
>> we just need to all be on the same page.
>
> That sounds like a reason to keep the governance of the libraries under
> the client tool project.

Hmmm... I think that may address 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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series

2018-09-27 Thread Dean Troyer
On Thu, Sep 27, 2018 at 9:06 AM, Doug Hellmann  wrote:
> I definitely think having details about the gaps would be a prerequisite
> for approving a goal, but I wonder if that's something 1 person could
> even do alone. Is this an area where a small team is needed?

Maybe, but it does break down along project/API lines for the most
part, only crossing in places like Matt mentioned where compute+volume
interact in server create, etc.

For the purposes of a goal, I think we need to be thinking more about
structural things than specific command changes.  Things like Monty
mentioned elsewhere in the thread about getting all of the exiting
client libs to correctly use an SDK adapter then behaviours converge
and the details of command changes become project-specific.

> We built cliff to be based on plugins to support this sort of work
> distribution, right?

We did, my concerns about splitting the OSC in-repo plugins out is
frankly more around losing control of things like command structure
and consistency, not about the code.  Looking at the loss of
consistency in plugins shows that is a hard thing to maintain across a
distributed set of groups.

>> 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
>> with installing OSC if that is still a big deal or should I let go of
>> that worry?
>
> Don't package managers just deal with this? I can pip/yum/apt install
> something and get all of its dependencies, right?

For those using that, yes.  The set of folks interacting with
OpenStack from a Windows desktop is not as large but their experience
is sometimes a painful one...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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series

2018-09-26 Thread Dean Troyer
On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann  wrote:
> I started documenting the compute API gaps in OSC last release [1]. It's a
> big gap and needs a lot of work, even for existing CLIs (the cold/live
> migration CLIs in OSC are a mess, and you can't even boot from volume where
> nova creates the volume for you). That's also why I put something into the
> etherpad about the OSC core team even being able to handle an onslaught of
> changes for a goal like this.

The OSC core team is very thin, yes, it seems as though companies
don't like to spend money on client-facing things...I'll be in the
hall following this thread should anyone want to talk...

The migration commands are a mess, mostly because I got them wrong to
start with and we have only tried to patch it up, this is one area I
think we need to wipe clean and fix properly.  Yay! Major version
release!

> I thought the same, and we talked about this at the Austin summit, but OSC
> is inconsistent about this (you can live migrate a server but you can't
> evacuate it - there is no CLI for evacuation). It also came up at the Stein
> PTG with Dean in the nova room giving us some direction. [2] I believe the
> summary of that discussion was:

> a) to deal with the core team sprawl, we could move the compute stuff out of
> python-openstackclient and into an osc-compute plugin (like the
> osc-placement plugin for the placement service); then we could create a new
> core team which would have python-openstackclient-core as a superset

This is not my first choice but is not terrible either...

> b) Dean suggested that we close the compute API gaps in the SDK first, but
> that could take a long time as well...but it sounded like we could use the
> SDK for things that existed in the SDK and use novaclient for things that
> didn't yet exist in the SDK

Yup, this can be done in parallel.  The unit of decision for use sdk
vs use XXXclient lib is per-API call.  If the client lib can use an
SDK adapter/session it becomes even better.  I think the priority for
what to address first should be guided by complete gaps in coverage
and the need for microversion-driven changes.

> This might be a candidate for one of these multi-release goals that the TC
> started talking about at the Stein PTG. I could see something like this
> being a goal for Stein:
>
> "Each project owns its own osc- plugin for OSC CLIs"
>
> That deals with the core team and sprawl issue, especially with stevemar
> being gone and dtroyer being distracted by shiny x-men bird related things.
> That also seems relatively manageable for all projects to do in a single
> release. Having a single-release goal of "close all gaps across all service
> types" is going to be extremely tough for any older projects that had CLIs
> before OSC was created (nova/cinder/glance/keystone). For newer projects,
> like placement, it's not a problem because they never created any other CLI
> outside of OSC.

I think the major difficulty here is simply how to migrate users from
today state to future state in a reasonable manner.  If we could teach
OSC how to handle the same command being defined in multiple plugins
properly (hello entrypoints!) it could be much simpler as we could
start creating the new plugins and switch as the new command
implementations become available rather than having a hard cutover.

Or maybe the definition of OSC v4 is as above and we just work at it
until complete and cut over at the end.  Note that the current APIs
that are in-repo (Compute, Identity, Image, Network, Object, Volume)
are all implemented using the plugin structure, OSC v4 could start as
the breaking out of those without command changes (except new
migration commands!) and then the plugins all re-write and update at
their own tempo.  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
with installing OSC if that is still a big deal or should I let go of
that worry?

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series

2018-09-26 Thread Dean Troyer
On Wed, Sep 26, 2018 at 3:01 PM, Doug Hellmann  wrote:
> Would it be useful to have the SDK work in OSC as a prerequisite to the
> goal work? I would hate to have folks have to write a bunch of things
> twice.

I don't think this is necessary, once we have the auth and service
discovery/version negotiation plumbing in OSC properly new things can
be done in OSC without having to wait for conversion.  Any of the
existing client libs that can utilize an adapter form the SDK makes
this even simpler for conversion.

> Do we have any sort of list of which projects aren't currently being
> handled by OSC? If we could get some help building such a list, that
> would help us understand the scope of the work.

We have asked plugins to maintain their presence in the OSC docs [0],
there are three listed there as not having plugins but I wouldn't
consider that exhaustive.  We also ask them to list their resource
names in [1] to reserve the name to help prevent name collisions.

> As far as admin features, I think we've been hesitant to add those to
> OSC in the past, but I can see the value. I wonder if having them in a
> separate library makes sense? Or is it better to have commands in the
> tool that regular users can't access, and just report the permission
> error when they try to run the command?

The admin/non-admin distinction has not been a hard rule in most
places, we have plenty of admin commands in OSC.  At times we have
talked about pulling those out of the OSC repo into an admin plugin, I
haven't encouraged that as I am not convinced of the value enough to
put aside other things to do it.  Due to configurable policy it also
is not clear what to include and exclude, to me it is a better user
experience, and more interoperable between 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.html#plugin-objects

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

2018-09-18 Thread Dean Troyer
On Tue, Sep 18, 2018 at 7:40 AM, Jeremy Stanley  wrote:
> I have yet to hear anyone provide first-hand confirmation that
> access to Freenode's IRC servers is explicitly blocked by the
> mainland Chinese government. There has been a lot of speculation
[...]

Data point: I have a couple of 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...@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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [sdk] Pruning core team

2018-08-10 Thread Dean Troyer
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...@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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][python-openstackclient] osc-included image signing

2018-06-28 Thread Dean Troyer
On Thu, Jun 28, 2018 at 8:04 AM, Josephine Seifert
 wrote:
>> Go ahead and post WIP reviews and we can look at it further.  To merge
>> I'll want all of the usual tests, docs, release notes, etc but don't
>> wait if that is not all done up front.
> Here are the two WIP reviews:
>
> cursive: https://review.openstack.org/#/c/578767/
> osc: https://review.openstack.org/#/c/578769/

So one problem I have here is the dependencies of cursive, all of
which become OSC dependencies if cursive is added.  It includes
oslo.log which OSC does not use and doesn't want to use for $REASONS
that boil down to assumptions it makes for server-side use that are
not good for client-side use.

cursive includes castellan which also includes oslo.log and
oslo.context, which I must admit I don't know how it affects a CLI
because we've never tried to include it before.  python-barbicanclient
is also included by cursive, which would make that a new permanent
dependency.  This may be acceptable, it is partially up to the
barbican team if they want to be subject to OSC testing that they may
not have now.

Looking at the changes you have to cursive, if that is all you need
from 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-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][python-openstackclient] osc-included image signing

2018-06-28 Thread Dean Troyer
On Thu, Jun 28, 2018 at 8:04 AM, Josephine Seifert
 wrote:
>> Go ahead and post WIP reviews and we can look at it further.  To merge
>> I'll want all of the usual tests, docs, release notes, etc but don't
>> wait if that is not all done up front.
> Here are the two WIP reviews:
>
> cursive: https://review.openstack.org/#/c/578767/
> osc: https://review.openstack.org/#/c/578769/

So one problem I have here is the dependencies of cursive, all of
which become OSC dependencies if cursive is added.  It includes
oslo.log which OSC does not use and doesn't want to use for $REASONS
that boil down to assumptions it makes for server-side use that are
not good for client-side use.

cursive includes castellan which also includes oslo.log and
oslo.context, which I must admit I don't know how it affects a CLI
because we've never tried to include it before.  python-barbicanclient
is also included by cursive, which would make that a new permanent
dependency.  This may be acceptable, it is partially up to the
barbican team if they want to be subject to OSC testing that they may
not have now.

Looking at the changes you have to cursive, if that is all you need
from 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-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][python-openstackclient] osc-included image signing

2018-06-20 Thread Dean Troyer
[Apologies for the relay in responding...]

On Fri, Jun 1, 2018 at 8:13 AM, Josephine Seifert
 wrote:
> our team has implemented a prototype for an osc-included image signing. We
> would like to propose a spec or something like this, but haven't found where
> to start at. So here is a brief concept of what we want to contribute:
>
> https://etherpad.openstack.org/p/osc-included_image_signing
>
> Please advise us which steps to take next!

This looks like a great addition, thanks!

I am not familiar with cursive, it is not a current dependency of OSC.
Also, does this depend on barbican client at all?  That is not a
direct dependency of OSC,  If it does have a hard dependency on
barbican client, we would need to handle the errors if it is not
installed.

We do not have a formal spec process in OSC, that etherpad[0[ and
story [1] look good.  Tasks 19810 and 19812 could likely be done in
the same review depending on how things are structured.

Go ahead and post WIP reviews and we can look at it further.  To merge
I'll want all of the usual tests, docs, release notes, etc but don't
wait if that is not all done up front.

dt


[0] https://etherpad.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...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [openstackclient][openstacksdk] why does openstackclient rely on openstacksdk for get a network client

2018-06-20 Thread Dean Troyer
On Tue, Jun 19, 2018 at 9:42 PM, zijian1...@163.com  wrote:
> Thks for replying, just want to confirm, you mentioned "We have intended to
> migrate everything to use
> OpenStackSDK", the current use of python-*client is:
> 1. OSC
> 2. all services that need to interact with other services (e.g.:  nova
> libraries: self.volume_api = volume_api or cinder.API())
> Do you mean that both of the above will be migrated to use the OpenStack
> SDK?

I am only directly speaking for OSC.  Initially we did not think that
services using the SDK would be feasible, Monty 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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [openstackclient][openstacksdk] why does openstackclient rely on openstacksdk for get a network client

2018-06-19 Thread Dean Troyer
On Tue, Jun 19, 2018 at 11:15 AM, 李健  wrote:
> So, my question is, why does the network service not use the
> python2-neutronclient to get the client like other core projects, but
> instead uses another separate project(openstacksdk)?

There were multiple reasons to not use neutron client lib for OSC and
the SDk was good enough at the time to use ut in spite of not being at
a 1.0 release.  We have intended to migrate everything to use
OpenStackSDK and eliminate OSC's use of the python-*client libraries
completely.  We are waiting on an SDK 1.0 release, it has stretched on
for years longer than originally anticipated but the changes we have
had to accommodate in the network commands in the past convinced me to
wait until it was declared stable, even though it has been nearly
stable for a while now.

> My personal opinion, openstacksdk is a project that can be used
> independently, it is mainly to provide a unified sdk for developers, so
> there should be no interdependence between python-xxxclient and
> openstacksdk, right?

Correct, OpenStackSDK has no dependency on any of the python-*client
libraries..  Its primary dependency is on keystoneauth for the core
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...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] StarlingX project status update

2018-06-12 Thread Dean Troyer
On Mon, Jun 11, 2018 at 5:02 PM, Emilien Macchi  wrote:
> While I agree with Doug that we assume good faith and hope for the best, I
> personally think we should help them (what we're doing now) but also make
> sure we DO NOT set a precedent. We could probably learn from this situation
> and document in our governance what the TC expects when companies have a
> fork and need to contribute back at some point. We all know StarlingX isn't
> alone and I'm pretty sure there are a lot of deployments out there who are
> in the same situation.

/me pus on ex-TC hat for a minute

Emilien, I totally agree with you here but would word it differently:
we should absolutely set a precedent, but one that exhibits how we
want to handle what ttx calls 'convergent' forks.  These already
exist, like it or not.  What I hope can be established is some
guidelines and boundaries on how to deal with these rather than just
reject them out-of-hand.

> I guess my point is, yes for helping StarlingX now but no for incubating
> future forks if that happens. Like Graham, I think these methods shouldn't
> be what we encourage in our position.

Again, I agree, we have said that sort 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

2018-05-25 Thread Dean Troyer
On Thu, May 24, 2018 at 11:23 PM, Tim Bell <tim.b...@cern.ch> wrote:
> I'd like to understand the phrase "StarlingX is an OpenStack Foundation Edge 
> focus area project".
>
> My understanding of the current situation is that "StarlingX would like to be 
> OpenStack Foundation Edge focus area project".
>
> I have not been able to keep up with all of the discussions so I'd be happy 
> for further URLs to help me understand the current situation and the 
> processes (formal/informal) to arrive at this conclusion.

Agreed Tim, my apologies 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 are at today.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

2018-05-23 Thread Dean Troyer
On Wed, May 23, 2018 at 2:20 PM, Brian Haley <haleyb@gmail.com> wrote:
> Even doing that is work - going through changes, finding nuggets, proposing
> new specs I don't think we can expect a project to even go there, it has
> to be driven by someone already involved in 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
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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

2018-05-23 Thread Dean Troyer
On Wed, May 23, 2018 at 1:24 PM, Matt Riedemann <mriede...@gmail.com> wrote:
> Rather than literally making this a priority, I expect most of the feeling
> is that because of the politics and pressure of competition with a fork in
> another foundation is driving the defensiveness about feeling pressured to
> prioritize review on whatever specs/patches are proposed as a result of the
> code dump.

David Letterman used to say "This is not a competition it is just an
exhibition.  No wagering!"  for Stupid Pet Tricks.

The feelings that is is a competition is one aspect that I want to
help ease if I can.  Once we have the list of individual
upstream-desired changes we can talk about priorities (we do have a
priority list internally) and desirability.

The targeted use cases for StarlingX/Titanium has requirements that do
not fit other use cases or may 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.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

2018-05-23 Thread Dean Troyer
On Wed, May 23, 2018 at 12:58 PM, Julia Kreger
<juliaashleykre...@gmail.com> wrote:
> There is definitely value to be gained for both projects in terms of a
> different point of view that might not have been able to play out in

Ironic is a bit different in this regard to the released code since
there _is_ overlap with the STX Bare Metal service.  There is also
not-overlapping aspects to it.  I would like to talk with you and the
Ironic team at some point about scope and goals for the long term.

> the public community, but since we're dealing with squashed commits of
> changes, it is really hard for us to delineate history/origin of code
> fragments, and without that it makes it near impossible for projects
> to even help them reconcile their technical debt because of that and
> the lacking context surrounding that. It would be so much more
> friendly to the community if we had stacks of patch files that we
> could work with git.

Unfortunately it was a requirement to not release the history.  There
are some bits that we were not allowed to release (for legal reasons,
not open core reasons) that are present in the history.  And yes it is
in most cases unusable to do anything more than browse for pulling
things upstream.

What I did manage to get was permission to publish the individual
commits on top of the upstream base that do not run afoul of the legal
issues.  Given that this is all against Pike and we need to propose to
master first, they are not likely directly usable but the information
needed for the upstream work will be available.  These have not been
cleaned up yet but I plan to add them directly to the repos containing
the squashes as they are done.

> Can I add myself to the list of confused people wanting to understand
> better? I can see and understand value, but context and understanding
> as to why as I mentioned above is going to be the main limiter for
> interaction.

I have heard multiple reasons why this has been done, this is one area
I am not going to go into detail about other than 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 there.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

2018-05-23 Thread Dean Troyer
On Wed, May 23, 2018 at 11:49 AM, Colleen Murphy <coll...@gazlene.net> wrote:
> It's also important to make the distinction between hosting something on 
> openstack.org infrastructure and recognizing it in an official capacity. 
> StarlingX is seeking both, but in my opinion the code hosting is not the 
> problem here.

StarlingX is an OpenStack Foundation Edge focus area project and is
seeking to use the CI infrastructure.  There may be a project or two
contained within that may make sense as OpenStack projects in the
not-called-big-tent-anymore sense but that is 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 for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [StarlingX] StarlingX code followup discussions

2018-05-22 Thread Dean Troyer
StarlingX (aka STX) was announced this week at the summit, there is a
PR to create project repos in Gerrit at [0]. STX is basically Wind
River's Titanium Cloud product, which is a turn-key cloud deployment.
For background I have started putting notes, some faq-ish questions
and references to blog-ish materials in [1].

The alternatives I have thought of or have been suggested so far all
seem to be worse in some way.  The major objections I have heard are
around the precedent and messaging of the existence of OpenStack
project forks, independent of the form they take[2].  There is a
secondary concern about OpenStack Foundation hosting fork of other
outside projects.

At this point I am planning to change the review[0] to only add the
repos for the new sub-projects so we can continue getting things set
up while the discussions continue on how best to handle the upstream
work.  I want to continue those discussions wherever they will be
productive, respond here or find me at the summit.  IRC discussion has
been in #openstack-tc so far.

More background

The set of STX repos include a number of patches to upstream projects,
most of which are intended to be proposed upstream.  The patches
include features specific to Titanium's use cases and bug fixes as
well as some bits that may or may not be useful in other use cases.
The intention is to reduce this technical debt to zero; there were a
handful of repos where the patch count was reduced to zero that we
were able to eliminate in the transition to StarlingX.  This is the
goal for all of the remaining upstream repos.

I chose to maintain the status of the Titanium upstream work as git
repos for developer and testing convenience, as opposed to publishing
patch file sets. Developers will need to re-create a repo locally in
order to work or test the code and create reviews (there are more git
challenges here). It would be challenging to do functional testing on
the rest of STX in CI without access to all of the code.

dt


[0] https://review.openstack.org/#/c/569562/
[1] https://etherpad.openstack.org/p/stx-faq
[2] 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 (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][swift] Setting storage policy for a container possible via the client?

2018-04-19 Thread Dean Troyer
On Thu, Apr 19, 2018 at 7:51 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Mark Kirkwood's message of 2018-04-19 16:47:58 +1200:
>> Swift has had storage policies for a while now. These are enabled by
>> setting the 'X-Storage-Policy' header on a container.
>>
>> It looks to me like this is not possible using openstack-client (even in
>> master branch) - while there is a 'set' operation for containers this
>> will *only* set  'Meta-*' type headers.
>>
>> It seems to me that adding this would be highly desirable. Is it in the
>> pipeline? If not I might see how much interest there is at my end for
>> adding such - as (famous last words) it looks pretty straightforward to do.
>
> I can't imagine why we wouldn't want to implement that and I'm not
> aware of anyone working on it. If you're interested and have time,
> please do work on the patch(es).

The primary thing that hinders Swift work like this is OSC does not
use swiftclient as it wasn't a standalone thing yet when I wrote that
bit (lifting much of the actual API code from swiftclient) .  We
decided a while ago to not add that dependency and drop the
OSC-specific object code and use the SDK when we start using SDK for
everything else, after there is an SDK 1.0 release.

Moving forward on this today using either OSC's api.object code or the
SDK would be fine, with the same SDK caveat we have with Neutron,
since SDK isn't 1.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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [sdk] git repo rename and storyboard migration

2018-03-22 Thread Dean Troyer
On Thu, Mar 22, 2018 at 7:42 AM, Akihiro Motoki <amot...@gmail.com> wrote:
> 2018-03-22 21:29 GMT+09:00 Monty Taylor <mord...@inaugust.com>:
>> I could see waiting until we move python-openstackclient. However, we've
>> got the issue already with shade bugs being in storyboard already and sdk
>> bugs being in launchpad. With shade moving to having its implementation be
>> in openstacksdk, over this cycle I expect the number of bugs people report
>> against shade wind up actually being against openstacksdk to increase quite
>> a bit.
>>
>> Maybe we should see if the python-openstackclient team wants to migrate
>> too?
>
> Although I have limited experience on storyboard, I think it is ready for
> our bug tracking.
> As Jens mentioned, not a small number of bugs are referred to from both OSC
> and SDK.
> One good news on OSC launchpad bug is that we do not use tag aggressively.
> If Dean is okay, I believe we can migrate to storyboard.

I am all in favor of migrating OSC to use to Storyboard, however I am
totally unable to give it any time in the near future.  If Akhiro or
anyone else wants 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...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][neutron][openstackclient] The way to assign floating IPs to VM

2018-03-05 Thread Dean Troyer
On Mon, Mar 5, 2018 at 10:56 AM, Andrey Kurilin <andr.kuri...@gmail.com> wrote:
> Dean, I propose a patch (https://review.openstack.org/549820) which should
> work for all environments where neutron is installed. Please check it when
> you have free time.

Thank you Andrey.  Monty started one approach, I just pushed up
https://review.openstack.org/#/c/549864/ as an example that follows
the pattern we[0] established in the Network commands long ago to
auto-detect between nova-net and Neutron.  This involves moving the
commands from the compute.v2.server classes to network.v2.floating_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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][neutron][openstackclient] The way to assign floating IPs to VM

2018-03-05 Thread Dean Troyer
On Mon, Mar 5, 2018 at 8:07 AM, Matt Riedemann <mriede...@gmail.com> wrote:
> On 3/5/2018 6:26 AM, Andrey Kurilin wrote:
>> - openstackclient
>>
>> * command `openstack server add floating ip` calls `add_floating_ip`
>> method of novaclient's server object[4]. This method is missed in the latest
>> novaclient (see [2]).
>>It means that this command is broken now.

>> So here we have 2 global issues:
>> - openstackclient has a broken command (or I missed something?)
>> - there is no easy way to associate a floating ip with a vm using CLI or
>> via python.

> I mentioned the related issue back in January:
>
> http://lists.openstack.org/pipermail/openstack-dev/2018-January/126741.html
>
> Adding a floating IP to an instance is possible using OSC CLI, it's
> essentially something like:
>
> a) get the server id (openstack server show/list)
> b) get the port id using the server id (openstack port list --device-id
> $server_id)
> c) assign the floating IP to the port (openstack floating ip set --port
> $port_id)


We keep removing Python API bindings from client libraries that are
still in use for old clouds that are still in much wider use than we
would like.  Why do we not give a rats ass about our users?
Especially when some deployers have multiple clouds lying about,
requiring them to maintain multiple venvs of CLIs is just stupid to be
able to work on their clouds and migrations to the cool new stuff.

OSC is not done because I have about 3 hours a week left to work on
it.  Continued shit like this isn't helping me want to keep going.
Maybe my brain is just snow-fried.   And for the love of all the snow
in Dublin, please, NOBODY USE THE SDK IN A SERVICE.  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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [docs] About the convention to use '.' instead of 'source'.

2018-02-20 Thread Dean Troyer
>> On 2018-02-18 03:55:51 -0600 (-0600), Monty Taylor wrote:
>> > That said - I completely agree with fungi on the description of
>> > the tradeoffs of each direction, and I do think it's valuable to
>> > pick one for the docs.

FWIW, DevStack declared long ago that it was built to use bash, even
though in some cases the shebang may even be /bin/sh.  While other
similar shells have been accommodated in the past they are considered
unsupported because we do not expect reviewers to know the subtlties
of similar shells.   Those who use zsh and friends 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.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][python-openstackclient] Consistency of option name

2018-02-12 Thread Dean Troyer
On Mon, Feb 12, 2018 at 9:13 AM, Graham Hayes <g...@ham.ie> wrote:
> OSC only predates Designate by 5 months ...

My bad, I didn't check dates.

> "Zone" was what we were recommend to use by the OSC devs at the time we
> wrote our OSC plugin, and at the time we were also *not* supposed to
> name space commands inside service parent (e.g. openstack zone create vs
> openstack dns zone create).

Namespacing commands and naming options are totally separate things.
It is likely I suggested --zone at the time, and in the context of DNS
commands it is very clear.  Also, in the context of Compute commands,
--zone meaning availability zone is also clear.

> For command flags --dns-zone seems like a good idea - but having a plain
> --zone is confusing when we have a top level "zone" object in the CLI,
> when the type of object that "--zone" refers to is different to
> "openstack zone "

Again, if there is confusion, things should be more specifically named
to remove the confusion.  Maybe allowing "zone" to be assumed to be a
DNS zone was a mistake, I've made plenty of those in OSC already, so
there is precedent, but it seemed reasonable at the time and we (OSC
team) do not control what external plugins do.

For example, I really resist using abbreviations in OSC, but in some
places to not do so is to buck trends that any semi-experienced user
in the field would expect.  The last discussion of 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 understandable, clear and even
expected by the users.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][python-openstackclient] Consistency of option name

2018-02-12 Thread Dean Troyer
On Mon, Feb 12, 2018 at 7:50 AM, Graham Hayes <g...@ham.ie> wrote:
> Please please move to `availability-zone` - zone is a DNS zone (seen as
> Keystone took Domain :) ) within OSC.

As stated in another message, changing the Compute usage of --zone
makes sense for OSC 4.  Two additional things here:

* Command option names have a lesser bar to clear (compared to
resource names which must be unique) for uniqueness, as they are by
definition context-sensitive.  Like trademarks, the primary objective
is to reduce user confusion.

* --zone is really generic and I would suggest that 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" is a better
fit.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][python-openstackclient] Consistency of option name

2018-02-12 Thread Dean Troyer
On Sun, Feb 11, 2018 at 10:18 PM, Hongbin Lu <hongbin...@gmail.com> wrote:
> I was working on the OSC plugin of my project and trying to choose a CLI
> option to represent the availability zone of the container. When I came
> across the existing commands, I saw some inconsistencies on the naming. Some
> commands use the syntax '--zone ', while others use the syntax
> '--availability-zone '. For example:
>
> * openstack host list ... [--zone ]
> * openstack aggregate create ... [--zone ]

These likely date back to the original command mapping I did and in
retrospect should have been --availability-zone.  However they have
been there since day 1 or 2.

> * openstack volume create ... [--availability-zone ]
> * openstack consistency group create ... [--availability-zone
> ]
>
> I wonder if it makes sense to address this inconsistency. Is it 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 some time.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Switching to longer development cycles

2017-12-14 Thread Dean Troyer
On Thu, Dec 14, 2017 at 10:37 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> What would our world look like if we treated inter-service dependencies like
> we do service-to-library dependencies and only integration test released
> components, rather than installing everything from source by default?

I've been struggling to catch up and haven't gotten through the office
hours log yet, but this summarizes the thing that keeps bounding
through my mind.  But it seems to me that much of the reaction to
ttx's proposal gets into things that are not directly
development-cycle-related.  It feels like we are continuing to treat
symptoms and not actually address root causes.

I think #1 on our top-wanted list for the Board needs to be to address
these root causes.  Continuing to not do this will become an
existential problem for OpenStack.  Look at the situation with Nova
and the amount of energy spent on trying to improve things there
without actually being able to address the real problems.  Some of
these problems are structural to the software, some of them are the
massive amount of inertia that a 6 year old project that needs to be
backward-compatible  inevitably carries.

The dev cycle discussion is (to pick a number) 80% focused on the
problems related to Nova: upgrade times, release deployment time, etc.

Clint brought up Swift earlier in the thread, and I think that is the
counter-example of what can happen with well-defined interfaces and
stable APIs.  Swift has been successful from the start with their
release model and fitting it into the overall OpenStack releases.
Why?  Because it does one thing, does it damn well, and does it with a
VERY stable API.  Some of the newer projects have also been able to
operate in this mode.

Even with the differences in how they were created, Cinder and Neutron
are still tightly tied to Nova in terms of upgrades and the
requirements to keep them coordinated in specifically controlled
releases.

Outside of those three projects, what others are experiencing the
sorts of problems being discussed here?  Is this (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.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Super fun unshelve image_ref bugs

2017-12-01 Thread Dean Troyer
On Fri, Dec 1, 2017 at 2:47 PM, Matt Riedemann <mriede...@gmail.com> wrote:
> Andrew Laski also mentioned in IRC that we didn't replace the original
> instance.image_ref with the shelved image id because the shelve operation
> should be transparent to the end user, they have the same image (not
> really), same volumes, same IPs, etc once they unshelve. And he mentioned
> that if you rebuild, for example, you'd then rebuild to the original image
> instead of the shelved snapshot image.

I was wondering about exactly this.  As a cloud user I would expect
rebuild without 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 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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [python-openstacksdk][shade] New cores proposed for shade/sdk

2017-11-30 Thread Dean Troyer
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 for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [openstack][zuul] About devstack plugin orders and the log to contain the running local.conf

2017-10-28 Thread Dean Troyer
On Sat, Oct 28, 2017 at 8:25 PM, gong_ys2004 <gong_ys2...@aliyun.com> wrote:
> 2. I cannot see the whole local.conf in the log dir
>
> the running local.conf is not shown in:
> http://logs.openstack.org/04/516004/4/check/tacker-functional-devstack/f365f21/controller/logs/
>
> Do anyone help me to find how to fix the problem at
> https://review.openstack.org/#/c/516004?

I have a DevStack review[0] to grab local.conf and set the groundwork
for the other config files we used to get; ianw made some good
suggestions that I am not going to get to for a day or three (flying
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 usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Interesting bug when unshelving an instance in an AZ and the AZ is gone

2017-10-16 Thread Dean Troyer
[not having a dog in this hunt, this is what I would expect as a cloud consumer]

On Mon, Oct 16, 2017 at 10:22 AM, Matt Riedemann <mriede...@gmail.com> wrote:
> - The user creates an instance in a non-default AZ.
> - They shelve offload the instance.
> - The admin deletes the AZ that the instance was using, for whatever reason.
> - The user unshelves the instance which goes back through scheduling and
> fails with NoValidHost because the AZ on the original request spec no longer
> exists.

> 1. How reasonable is it for a user to expect in a stable production
> environment that AZs are going to be deleted from under them? We actually
> have a spec related to this but with AZ renames:

Change happens...

> 2. Should we null out the instance.availability_zone when it's shelved
> offloaded like we do for the instance.host and instance.node attributes?
> Similarly, we would not take into account the RequestSpec.availability_zone
> when scheduling during unshelve. I tend to prefer this option because once
> you unshelve offload an instance, it's no longer associated with a host and
> therefore no longer associated with an AZ. However, is it reasonable to
> assume that the user doesn't care that the instance, once unshelved, is no
> longer in the originally requested AZ? Probably not a safe assumption.

Agreed, unless we keep track that the user specified a default or no
AZ at create.

I think nulling the AZ when the original doesn't exist would be
reasonable from a user standpoint, but I'd feel handcuffed if that
happens and I can not select a new AZ. Or throwing a specific error
and letting the user handle it in #3 below:

> 3. When a user unshelves, they can't propose a new AZ (and I don't think we
> want to add that capability to the unshelve API). So if the original AZ is

Here is my question... if I can specify an AZ on create, why not on
unshelve?  Is it the image location movement under the hood?

> gone, should we automatically remove the RequestSpec.availability_zone when
> scheduling? I tend to not like this as it's very implicit and the user could
> see the AZ on their instance change before and after unshelve and be
> confused.

Agreed that explicit is better than implicit.

> 4. We could simply do nothing about this specific bug and assert the
> behavior is correct. The user requested an instance in a specific AZ,
> shelved that instance and when they wanted to unshelve it, it's no longer
> available so it fails. The user would have to delete the instance and create
> a new instance from the shelve snapshot image in a new AZ. If we implemented

I do not have the list of things in my head that are preserved in
shelve/unshelve that would be lost in a recreate, but that's where my
worry would come.  Presumably that is why I shelved in the first place
rather than snapshotting the server and removing it.  Depends on the
cost models too, if I lose my 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 probably do not mind this, as an operator I'd likely be unhappy.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa][infra][devstack] Changes to devstack-core for zuul v3 migration

2017-10-10 Thread Dean Troyer
On Tue, Oct 10, 2017 at 1:15 PM, Andrea Frittoli
<andrea.fritt...@gmail.com> wrote:
> - we will treat +1 from infra-core members on devstack changes in the
> ansible bits as +2
> - add clarkb to devstack-core, since he's quite aware of the the devstack
> codebase

+2 on both 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.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone][zuul] A Sad Farewell

2017-10-03 Thread Dean Troyer
On Mon, Oct 2, 2017 at 9:13 PM, Jamie Lennox <jamielen...@gmail.com> wrote:
> I'm really sad to announce that I'll be leaving the OpenStack community (at
> least for a while), I've accepted a new position unrelated to OpenStack
> that'll begin in a few weeks, and am going to be mostly on holiday until
> then.

No, this just will not do. -2

Seriously, it has been a great pleasure to 'try to take over the
world' with you, at least that is what I recall as the goal we set in
Hong Kong.  The entire interaction of Python-based clients with
OpenStack has been made so much 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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Cinder V1 API Removal

2017-09-10 Thread Dean Troyer
[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...@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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Cinder V1 API Removal

2017-09-09 Thread Dean Troyer
On Thu, Sep 7, 2017 at 4:26 PM, Sean McGinnis <sean.mcgin...@gmx.com> wrote:
> Well, it's now been many releases, and we've had the v1 API disabled by
> default for awhile now. Patch
> https://review.openstack.org/#/c/499342/ now removes that API. Queens
> onward, it will not be possible
> to run with V1 anymore.

It looks like DevStack had two approaches to dealing with the Volume
v1 endpoint [0], [1] (did I miss any others?).  What is the
recommended configuration in a no-v1 world for the 'volume' service
endpoint?  Go ahead and set the endpoint without the 'v1' like we have
always wanted to do?

I'm finding I need to dynamically check for volume v1 now in the OSC
functional tests (we can't remove v1 support for a while yet) which
wants the new full version discovery which wants...  it's 'wants' all
the way down. :)

dt

[0] https://review.openstack.org/#/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?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance] docs: architecture or hw_architecture

2017-08-23 Thread Dean Troyer
On Wed, Aug 23, 2017 at 12:33 PM, Brian Rosmaita
<rosmaita.foss...@gmail.com> wrote:
> My point is just that Glance went one way on this, Nova went a
> different way, and users are left hanging.  My secondary point is that
> it might be useful to catalog these things in the metadata 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
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/mailman/listinfo/openstack-dev


Re: [openstack-dev] openstack/openstackclient vs openstack/python-openstackclient

2017-08-23 Thread Dean Troyer
On Wed, Aug 23, 2017 at 12:39 PM, David Medberry <openst...@medberry.net> wrote:
> What's the relationship between
>
> openstack/openstackclient

A meta-package that depends on python-openstackclient and all of the
known (registered with OSC) plugin packages.  This will get you
_everything_ that we know about, but may pull in dependencies that are
unneeded for many users.

> and
>
> openstack/python-openstackclient

A package that includes the commands for Compute, Identity, Image,
Object Store and Volume.  All others are plugins in separate packages.

The 'openstackclient' 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 usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone][api] Backwards incompatible changes based on config

2017-08-07 Thread Dean Troyer
On Mon, Aug 7, 2017 at 4:00 AM, Chris Dent <cdent...@anticdent.org> wrote:
> Many deployments are several months behind. If _all_ (or even many)
> deployments are that far behind, maybe we could consider saving ourselves
> some pain?

I would agree with this when we get some solid feedback on the impact.
We started with CD as one of the fundamental
constraints^H^H^H^H^Hgoals and to drop it should be a deliberate
decision.

In addition to direct deployments, I found things like this [0] in a
quick search for who is publicly saying they (still) do CD, it is a
category I had not considered before and makes me think that this kind
of decision has a wider impact range than we may be aware of.

Looking in https://www.openstack.org/analytics for the 2017 User
Survey shows no production deployments on "trunk" but of course that
doesn't mean there are none.  I wonder 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 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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

2017-08-04 Thread Dean Troyer
On Fri, Aug 4, 2017 at 11:52 AM, Monty Taylor <mord...@inaugust.com> wrote:
[...]
> * Both shade and python-openstackclient have investigated using openstacksdk
> as their REST layer but were unable to because it puts some abstractions in
> layers that make it impossible to do some of the advanced things we need.

OSC _does_ use the SDK for all Network API commands.  That was a
mistake in the sense that we did it before SDK 1.0 was released and
still do not have 1.0.

> * openstacksdk has internal implementations of things that exist at
> different points in the stack. We just added full support for version
> service and version discovery to keystoneauth, but openstacksdk has its own
> layer for that so it both can't use the ksa implementation and is not
> compliant with the API-WG consume guidelines.

This was intended to make it free from dependencies, when first
concieved, none of these other libs existed.

I am coming around to believe that we need to slice a couple more
things up so they can be composed as needed rather then bite off the
entire thing in once piece.

[...]

> I'd propose we have the shade team adopt the python-openstacksdk codebase.

++

> This is obviously an aggressive suggestion and essentially represents a
> takeover of a project. We don't have the luxury of humans to work on things
> that we once had, so I think as a community we should be realistic about the
> benefits of consolidation and the downside to continuing to have 2 different
> python SDKs.

++

I thought it would be natural for OSC to adopt the SDK someday if
Brian did not get around to making it official, but the current
circumstances make it clear that we (OSC) do not have the resources to
do this.  This proposal is much better and leads to a natural
coalescence of the parallel goals and projects.

> Doing that implies the following:
>
> * Rework the underlying guts of openstacksdk to make it possible to replace
> shade's REST layer with openstacksdk. openstacksdk still doesn't have a 1.0
> release, so we can break the few things we'll need to break.

Sigh.  OSC has been using the Network components of the SDK for a long
time in spite of SDK not being at 1.0.  In retrospect that was a
mistake on my part but I believed at the time that 1.0 was close and
we had already ignored Network for far too long.  We already have one
compatibility layer in the SDK due to the proxy refactor work that was
supposed to be the last thing before 1.0.

[...]

> * Merge the two repos and retire one of them. Specifics on the mechanics of
> this below, but this will either result in moving the resource and service
> layer in openstacksdk into shade and adding appropriate attributes to the
> shade.OpenStackCloud object, or moving the shade.OpenStackCloud into
> something like openstack.cloud and making a shade backwards-compate shim. I
> lean towards the first, as we've been telling devs "use shade to talk to
> OpenStack" at hackathons and bootcamps and I'd rather avoid the messaging
> shift. However, pointing to an SDK called "The Python OpenStack SDK" and
> telling people to use it certainly has its benefits from a messaging
> perspective.

I don't have a big concern about which repo is maintained.  For OSC I
want what amounts to a low-level REST API, one example of which can be
found in openstackclient.api.*.  Currently Shade is not quite the
right thing to back a CLI but now has the layer I want, and SDK does
not have that layer at all (it was proposed very early on and not
merged).

Is it better to have a single monolithic thing that has three
conceptual layers internally that can be individually consumed or to
have three things that get layered as needed?

> * drop keystoneauth.Session subclass. It's over-riding things at the wrong
> layer. keystoneauth Adapter is the thing it wants to be.

FWIW, OSC has this problem too...

> * suitability for python-openstackclient. Dean and Steve have been laying in
> the groundwork for doing direct-REST in python-openstackclient because
> python-*client are a mess from an end-user perspective and openstacksdk
> isn't suitable. If we can sync on requirements hopefully we can produce
> something that python-openstackclient can honestly use for that layer
> instead of needing local code.

As I mentioned, we already use the Networking portions of SDK, even
without a 1.0, and it has bit us already a couple of times.  It has
long been my plan to convert to using the SDK, but that was when I
believed there would also be a lower-level API exposed that did not
require all of the application-level goodness and abstractions.

I personally feel like splitting out the low-level 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 

Re: [openstack-dev] [nova][docs] Concerns with docs migration

2017-08-02 Thread Dean Troyer
On Wed, Aug 2, 2017 at 11:20 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> My gut response is to say that if the example uses nova-manage or
> one of the nova service executables, then that makes sense to leave
> in the nova tree, but otherwise it should go into either the
> python-novaclient or python-openstackclient repositories (depending
> on which command line tool is used in the example).

I don't think this is a good rule of thumb...

> On the other hand, I can see that being somewhat confusing for
> someone who lands at the nova docs and can't find instructions for
> how to use it. Maybe less confusing, though, than if I am not
> *running* nova but am trying to use a nova deployed by someone else
> and I start from the python-novaclient or python-openstackclient
> docs because I installed one of those in order to talk to nova.

When the point of the example is to illustrate configuring nova, the
example should stay with the nova code, even if it uses novaclient or
osc.  The examples that are about _using_ novaclient or osc belong in
those repos, but where they are just a means to configuring something
in nova, they should remain with nova and use the tools that users are
expected to be familiar with (novaclient and/or osc in this example).

> I thought "put the docs with the code" would be a simple enough
> rule that we wouldn't have to think too hard about where to put
> individual example files, which 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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Status update, July 7th

2017-07-11 Thread Dean Troyer
On Fri, Jul 7, 2017 at 3:19 AM, Thierry Carrez <thie...@openstack.org> wrote:
> == Need for a TC meeting next Tuesday ==
[...]
> others). Who is up for discussing those items at our usual meeting slot
> time on Tuesday ?

I am unlikely to make the meeting, travel plans are more fluid 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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [qa] New upgrade test tool proposal.

2017-06-27 Thread Dean Troyer
On Tue, Jun 27, 2017 at 1:37 PM, Jay Pipes <jaypi...@gmail.com> wrote:
> Hi Castulo, sorry for the delayed response on this. Has your team moved
> forward on any of this?

IIRC this work was impacted by the OSIC shutdown, I believe it is not
currently on anyone's radar.

> What about the Grenade testing framework that uses devstack as its
> deployment system was not useful or usable for you?

I can take at least part of the blame in encouraging them to not
attempt to leverage Grenade directly.  Grenade needs to be replaced as
it has far out-lived its expected life[0].

Grenade was built to do static in-place upgrades and the fact that it
has been pushed as far as it has is a happy surprise to me.  However,
it is fundamentally limited in its abilities as a test orchestrator,
implementing robust multi-node capabilities and the granularity that
is required to properly do upgrade testing really needs a reboot.  In
a well-funded world that would include replacing DevStack too, which
while nice is not strictly necessary to achieve the testing goals they
had.

The thing that Grenade and DevStack have going for them besides
inertia is that they are not otherwise tied to any deployment
strategy.  Starting over from scratch really is not an option at this
point, something existing really does need to be leveraged even though
it may hurt some feelings along the way for the project(s) not chosen.

dt


[0] Seriously, I never expected Grenade (or DevStack for that 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 for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] How to handle nova show --minimal with embedded flavors

2017-06-20 Thread Dean Troyer
On Tue, Jun 20, 2017 at 12:07 PM, Chris Friesen
<chris.frie...@windriver.com> wrote:
> In the existing novaclient code for show/rebuild, the --minimal option just
> skips doing the lookups on the flavor/image as described in the help text.
> It doesn't affect the other ~40 fields in the instance.  After the new
> microversion we already have the flavor details without doing the flavor
> lookup so I thought it made sense to display them.
>
> I suppose an argument could be made that for consistency we should keep the
> output with --minimal similar to what it 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

-- 

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

2017-06-16 Thread Dean Troyer
On Fri, Jun 16, 2017 at 8:57 AM, Emilien Macchi <emil...@redhat.com> wrote:
> Regarding all the company efforts to invest in one deployment tool,
> it's going to be super hard to find The OneTrue and convince everyone
> else to work on it.

The idea is not that everyone works on it, it is simply that OpenStack
_does_ have one single known tested common way to do things, ie
fulfill the role that many people think DevStack should have been when
not used for dev/testing. I make this point not to suggest that this
is the way forward, but as the starting point from which we hear a LOT
of requests and questions.

> Future will tell us but it's possible that deployments tools will be
> reduced to 2 or 3 projects if it continues that way (Fuel is slowly
> dying, Puppet OpenStack has less and less contributors, same for Chef
> afik, etc).

This is the market effects 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

-- 

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project

2017-06-15 Thread Dean Troyer
On Thu, Jun 15, 2017 at 10:33 AM, Jay Pipes <jaypi...@gmail.com> wrote:
> I'd fully support the removal of all deployment projects from the "official
> OpenStack projects list".

Nice to hear Jay! :)

It was intentional from the beginning to not be in the deployment
space, we allowed those projects in (not unanimously IIRC) and most of
them did not evolve as expected.

I would not mind picking one winner and spending effort making an
extremely easy, smooth, upgradable install that is The OneTrue
OpenStack, I do not expect us to ever agree what that will look like
so it 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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

2017-05-23 Thread Dean Troyer
On Tue, May 23, 2017 at 3:42 PM, Sean McGinnis <sean.mcgin...@gmx.com> wrote:
>
>> If it's just too much debt and risk of slippery slope type arguments on
>> the Nova side (and that's fair, after lengthy conversations with Nova folks
>> I get it), do we consider just orchestrating this from say OpenStack Client
>> completely?  The last resort (and it's an awful option) is orchestrate the
>> whole thing from Cinder.  We can certainly make calls to Nova and pass in
>> the volume using the semantics that are already accepted and in use.
>>
>> John
>>
>
> /me runs away screaming!

Now I know Sean's weakness...

In this particular case it may not be necessary, but I think early
implementation of composite features in clients is actually the right
way to prove the utility of these things going forward.  Establish and
document the process, implement in a way for users to opt-in, and move
into the services as they are proven useful.  With the magic of
microversions we can then migrate from client-side to server-side as
the implementations roll through the deployment lifecycle.

This last bit is important.   Even today many of our users are unable
to take advantage of useful features that are already over a year old
due to the upgrade delay that production deployments see.
Implementing new things in clients helps users on existing clouds.
Sure other client implementations are left to their own work, but they
should 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...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][all] Missing answers on Pike release goals

2017-05-23 Thread Dean Troyer
OK, I'll bite, being one of the until-last-week offenders...

On Tue, May 23, 2017 at 4:59 AM, Thierry Carrez <thie...@openstack.org> wrote:
> As part of release management we remind projects of the release cycle
> deadlines, including the ones regarding the release goals process.
>
> According to [1], "each PTL is responsible for adding their planning
> artifact links to the goal document before the first milestone
> deadline", and "if the goal does not apply to a project or the project
> has already met the goal, the PTL should explain why that is the case,
> instead of linking to planning artifacts".
>
> However, for Pike goals we are 6 weeks past the pike-1 milestone, and we
> still have about half the project teams that haven't provided answers
> (despite two reminders posted in the release countdown emails). Such a
> large share goes beyond the usual occasional misses, and points to a
> more systemic issue, that we might want to address before the Queens
> campaign starts.
>
> A few questions to bootstrap the discussion:
>
> - Is it that the reporting process is too heavy ? (requiring answers
> from projects that are obviously unaffected)

I've thought about this, OSC was unaffected by one of the goals but
not the other, so I can't really hide in this bucket.  It really is
not that hard to put up a review saying "not me".

> - Is it that people ignore the deadlines and missed the reminders ?
> (some unaffected project teams also do not do releases, and therefore
> ignore the release countdown emails)

In my case, not so much "ignore" but "put off until tomorrow" where
tomorrow turned in to 6 weeks.  I really don't have a hard reason
other than simply not prioritizing it because I knew one of the goals
was going to take some coordination work

> - Is it that in periods of resource constriction, having release-wide
> goals is just too ambitious ? (although anecdotal data shows that most
> projects have already completed their goals)

While this may certainly be a possibility, I don't think we should
give in to the temptation to blame too much on losing people.  OSC was
hit by this too, yet the loss of core and contributors did not affect
the goals not getting done, that falls squarely on the PTL in this
case.

> - Is it that the goals should be more clearly owned by the community
> beyond just the TC? (and therefore the goals should be maintained in a
> repository with simpler approval rules and a larger approval group)

I do think that at least the perception of the goals being community
things should be increased if we can.  We fall in to the problem of
the TC proposing something and getting pushback about projects being
forced to do more work, yet we hear so much about how the TC needs to
take more leadership in technical direction (see TC vision feedback
for the latest round of this).

I'm not 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

-- 

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

2017-05-19 Thread Dean Troyer
On Fri, May 19, 2017 at 4:01 PM, Matt Riedemann <mriede...@gmail.com> wrote:
> I'm confused by this. Creating a server takes a volume ID if you're booting
> from volume, and that's actually preferred (by nova devs) since then Nova
> doesn't have to orchestrate the creation of the volume in the compute
> service and then poll until it's available.
>
> Same for ports - nova can create the port (default action) or get a port at
> server creation time, which is required if you're doing trunk ports or
> sr-iov / fancy pants ports.
>
> Am I misunderstanding what you're saying is missing?

It turns out those are bad examples, they do accept IDs.

The point though was there _are_ times when what you want is not what
the opinionated composed API gives you (as much as I _do_ like those).
It isn't so much making more REST calls, but a similar number of
different 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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

2017-05-19 Thread Dean Troyer
On Fri, May 19, 2017 at 1:04 PM, Sean Dague <s...@dague.net> wrote:
> These should be used as ways to experiment with the kinds of interfaces
> we want cheaply, then take them back into services (which is a more
> expensive process involving compatibility stories, deeper documentation,
> performance implications, and the like), not an end game on their own.

I totally agree here.  But I also see the rate of progress for many
and varied reasons, and want to make users lives easier now.

Have any of the lessons already learned from Shade or OSC made it into
services yet?  I think a few may have, "get me a network" being the
obvious one.  But that still took a lot of work (granted that one _is_
complicated).

> You can get the behavior. It also has other behaviors. I'm not sure any
> user has actually argued for "please make me do more rest calls to
> create a server".

Maybe not in those words, but "give me the tools to do what I need"
has been heard often.  Sometimes those tools are composable
primitives, sometimes they are helpful opinionated interfaces.  I've
already done the helpful opinionated stuff in OSC here (accept 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Boston Forum session recap - searchlight integration

2017-05-19 Thread Dean Troyer
On Thu, May 18, 2017 at 4:21 PM, Matt Riedemann <mriede...@gmail.com> wrote:
> Since sorting instances across cells is the main issue, it was also
> suggested that we allow a config option to disable sorting in the API. It
> was stated this would be without a microversion, and filtering/paging would
> still be supported. I'm personally skeptical about how this could be
> consider inter-operable or discoverable for API users, and would need more
> thought and input from users like Monty Taylor and Clark Boylan.

Please please please make that config option discoverable, do not
propagate that silent config option pattern any more.  Please.

This is totally a microversion-required situation in my view as the
API will behave differently and clients will need to do the sorting
locally if that is what they require.  Doing it locally is (usually)
fine, but we need to 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.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] Is the pendulum swinging on PaaS layers?

2017-05-19 Thread Dean Troyer
On Fri, May 19, 2017 at 11:53 AM, Chris Friesen
<chris.frie...@windriver.com> wrote:
> ..., but it seems to me that the logical
> extension of that is to expose simple orthogonal APIs where the nova boot
> request should only take neutron port ids and cinder volume ids.  The actual
> setup of those ports/volumes would be done by neutron and cinder.
>
> It seems somewhat arbitrary to say "for historical reasons this subset of
> simple things can be done directly in a nova boot command, but for more
> complicated stuff you have to go use these other commands".  I think there's
> an argument to be made that it would be better to be consistent even for the
> simple things.

cdent mentioned enamel[0] above, and there is also oaktree[1], both of
which are wrapper/proxy services in front of existing OpenStack APIs.
I don't know enough about enamel yet, but one of the things I like
about oaktree is that it is not required to be deployed by the cloud
operator to be useful, I could set it up and proxy Rax and/or
CityCloud and/or mtreinish's closet cloud equally well.

The fact that these exist, and things like shade itself, are clues
that we are not meeting the needs of API consumers.  I don't think
anyone disagrees with that; let me know if you do and I'll update my
thoughts.

First and foremost, we need to have the primitive operations that get
composed into the higher-level ones available.  Just picking "POST
/server" as an example, we do not have that today.  Chris mentions
above the low-level version should take IDs for all of the associated
resources and no magic happening behind the scenes.  I think this
should be our top priority, everything else builds on top of that, via
either in-service APIs or proxies or library wrappers, whatever a) can
get implemented and b) makes sense for the use case.

dt

[BTW, I made this same type of proposal for the OpenStack SDK a few
years ago and it went unmerged, so at some level folks do not agree
this is necessary. I look now at what the Shade folk are doing about
building 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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][swg] Updates on the TC Vision for 2019

2017-05-17 Thread Dean Troyer
On Wed, May 17, 2017 at 1:47 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> The timeline depends on who signed up to do the next revision. Did
> we get someone to do that, yet, or are we still looking for a
> volunteer?  (Note that I am not volunteering here, just asking for
> status.)

I believe John (johnthetubaguy),Chris (cdent) and I (dtroyer) are the
ones identified to drive the next steps.  Timing-wise, having this
wrapped up by 2nd week of June suits me great as I am planning some
time off about then.  I see that as having a solid 'final' proposal by
then, not 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.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][all] Do we need a #openstack-tc IRC channel

2017-05-16 Thread Dean Troyer
On Tue, May 16, 2017 at 1:02 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> rooters these days). Something like "tc-members" can be used to
> address a question specifically to those on the TC who happen to be
> around and paying attention and also gives people looking at the
> logs a useful string to grep/search/whatever. I've gone ahead and
> configured my client to highlight on that now.

Awesome idea... this may also be as close to an in-band tag (ML
subject-like tag) as we're going to get short of #topic in IRC. (/me
avoids discussion of the effectiveness 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-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][all] Do we need a #openstack-tc IRC channel

2017-05-16 Thread Dean Troyer
On Tue, May 16, 2017 at 10:17 AM, Sean McGinnis <sean.mcgin...@gmx.com> wrote:
> If we just use -dev, there is a high chance there will be a lot of cross-
> talk during discussions. There would also be a lot of effort to grep
> through the full day of activity to find things relevant to TC
> discussions. If we have a dedicated channel for this, it makes it very
> easy for anyone to know where to go to get a clean, easy to read capture
> of all relevant discussions. I think that will be important with the
> lack of a captured and summarized meeting to look at.

Right now the filtering aspect is swaying me to a dedicated channel.
There is really no way to extract topics out of IRC logs, and for many
discussions we do not need to be able to do that.  Here we are talking
about the background information for decisions that will be summarized
and recorded elsewhere.

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 Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

2017-05-05 Thread Dean Troyer
On Fri, May 5, 2017 at 3:39 PM, Davanum Srinivas <dava...@gmail.com> wrote:
> "If we had an LTS branch and a solid governance model" - The way to
> make it happen is for everyone to show up in the Stable team, do the
> work that is need to define/setup etc..
>
> Who is up for it? Please show up in the next weekly meeting and get
> active in the work needed to take care of the current stable work and
> the work needed to setup a LTS.

Thank you dims, this gets said every time we have this conversation,
and at best new interest wanes after a month, at worst nothing
changes.

I'm going to adopt sdague's stance here and ask for specifics.  Octave
(quoted in dims' first line above) suggests LTS + governance is the
solution.  Make specific proposals that include actionable tasks.
Include a clear problem statement so we know _which_ problem is being
solved.

The number one task for LTS is dims' suggestion above, show up next
week.   Number two is to sustain the level of interest that will be
expressed next week for 6 months and prove that there are resources
available and fully trained and operable before Newton is EOL.

I can't judge if starting 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 the party.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

2017-05-05 Thread Dean Troyer
On Fri, May 5, 2017 at 11:36 AM, Alex Schultz <aschu...@redhat.com> wrote:
> configuration and usability issues. But those aren't exciting so
> people don't want to work on them...

[Not picking on Alex here, but I've seen this repeated again in this
thread like every other one]

s/people/corporate project managers/

Yes, there are individual preferences involved here, but those of us
who are in a position to CHOOSE which projects we invest in are
actually in the minority, and shrinking.

The choices of what contributing companies invest in are largely
determined by their customers, or where they feel their business needs
to go.  Infrastructure, SDKs, documentation, none of these are on any
of the public roadmaps that I have seen (I have not seen them all so
speak up where I am wrong here).

Those who are customers of these sponsor/contributor companies also
need to be 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
dtro...@gmail.com


Tragedy.  Commons.  Rinse.  Repeat.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

2017-05-05 Thread Dean Troyer
On Fri, May 5, 2017 at 7:16 AM, Sean Dague <s...@dague.net> wrote:
> The general statement of "people care more about features than
> usability/stability" gets thrown around a lot. And gets lots of head
> nodding. But rarely comes with specifics.

I think a lot of this general sentiment comes from watching what gets
the investment from contributors, specifically from contributing
companies.  HP may have been an aberration for a time given the
quantity of infra folk they once employed, but take a look at the
distribution between feature work and non-feature work that our major
contributing companies sponsor.

Maybe it is time to set up direct sponsorship for some of this work
that keeps coming up as important but "nobody wants to pay for it".
Like an endowed chair or just a GoFundMe that lets someone continue to
be the Stable Branch Overlord.  It is the sort of work that no single
company wants to be on the hook for, nor is it a good idea from the
community perspective to be single sourced in that regard (again, the
infra situation last fall) so lets make it easy for downstream
consumers to share the funding of the upstream work they all want to
see done but do not want or can not afford the responsibility of
taking on themselves.

You might say we already do this, the Foundation employs people to
work directly on these things, and yes they do to great effect.  But
this topic keeps coming up because it is a specific request for
specific OpenStack 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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

2017-05-03 Thread Dean Troyer
On Tue, May 2, 2017 at 7:32 PM, Adrian Turjak <adri...@catalyst.net.nz> wrote:
> Shade in this context is both really easy, and harder since I can't just
> give it the same session so it can reuse the same token. I've tried
> seeing if I can pilfer the OpenStackCloudConfig from OSC but passing
> that to shade seemed to break. If you run that interpreter command you
> can explore the OSC objects too. "self.app.cloud_config" or
> "self.app.cloud" appears to be close to what we want, but I can't get it
> to play nice with shade as it appears to be a OSC extension of the
> os-client-config class.

With last week's release of os-client-config 1.27.0 and osc-lib 1.5.1
and the addition of these to global-requirements minimums for today's
OSC 3.10.0 release we are in a place to move most of the special-case
code back in to osc-lib and os-client-config.  Much of this is due to
backward-compatibility issues that OSC needed to handle.

> If the interpreter is started from envvars you can do "cloud =
> openstack_cloud()" and shade does the right thing. If it was started
> with --os-cloud then you can also do "cloud =
> openstack_cloud(cloud=self.app.cloud.config.get('cloud'))". The latter
> also works with envvars as "self.app.cloud.config.get('cloud')" returns
> an empty string so shade looks at envvars. I can easily make a function
> that just returns shade with a new token, just kind of sucks that there
> is no way to pass it a valid session/token for it to reuse. Would be
> fantastic if you can take a gander at that as I don't know that much
> about Shade. I'd prefer to have this thing use a single shared session
> or token as much as possible.

Both OSC and Shade use ksa Sessions, that bit should be directly
sharable and includes the token handling.  OSC's auth stuff changed a
bit in the 3.10.0 release in the first step of simplifying it and
actually being able to use os-client-config as intended.  There are a
bunch of timing issues regarding _when_ auth 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 Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

2017-05-03 Thread Dean Troyer
On Mon, May 1, 2017 at 11:11 PM, Adrian Turjak <adri...@catalyst.net.nz> wrote:
> As part of my dev work I recently put together a cool little tool which
> lets me have much easier access to the various OpenStack python clients
> in the scope of a python interpreter session. The first version was a
> little rough and without os-client-config support. The current version
> is now a plugin for the openstackclient and introduces a command that
> simply authenticates you, sets up the environment and helper tools, and
> then drops you into an ipython interactive session. The helper stuff is
> fairly simple, but combined with the features of ipython it really lets
> you start playing with the tools quickly, and by piggybacking onto
> openstackclient I get access to a lot of the niceties and inbuilt auth
> mechanisms.
>
> It is useful for learning, testing, or development against the various
> openstack client libraries, and even as an ops tool to quickly run some
> basic actions without having to resort to weird or silly bash command
> combinations.

This is at the other end of the spectrum of client usage from the CLI
in that it takes a very developer-like view of the APIs.  OSC has its
interactive mode (using cmd2) that is just a command loop without even
the ability to change global settings.  My hunch is that something in
between would be really useful, but I am not interested in creating
yet another DSL for this to include flow control and branching.

You mentioned Shade, which falls somewhere in between as it implements
a lot of logic to hide differences in clouds and ease dealing with
some of our API warts.  What would you think about producing a Python
mirror of the CLI interface with resource names, option names,
everything, but in Python.  I have not thought all the way through
this yet, but think we could take advantage of using the cliff command
classes and be able to re-use all of the bits already written.

This also magnifies the things we need to add to (or factor out of)
OSC to make it truly 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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [OSC] OpenStackClient release and core team and meetings

2017-05-03 Thread Dean Troyer
First of all, I would like to say how glad I am to have seen the two
recent messages regarding other OpenStack client-side projects.  More
projects like this raise the visibility of all of the client-side work
as it illustrates the importance of the consumer side of OpenStack
APIs in the minds of those watching what we do (/me waves at project
managers and other corporate resource deciders).

## Meetings

OSC has a split meeting schedule in an attempt to accommodate our
diverse time zones.  Part of the problem with that is keeping track of
odd or even weeks and as a result we've been missing a couple of
meetings.  I do not plan to change the schedule[0], but I _do_ plan to
start sending meeting reminders to the ML as that seems to work well
for other teams with a split schedule.  So here is the first:

The next OpenStackClient meeting is set for Thursday May 4 at 1300 UTC
in #openstack-meeting-3.

## 3.10.0 Release

OpenStackClient 3.10.0 was released this morning and includes a number
of things that I think bear highlighting.

* With the removal of the nova-network/proxy code in novaclient we
found ourselves with a hole and re-implemented the set of REST calls
that OSC required to continue to support networks and security groups
on nova-network clouds.  In the process of doing this we discovered a
CLI change that was required in 'network create', the --subnet option
is actually required (for nova-network only) for the call to succeed
so we now enforce that in the command.
* One other incompatible CLI change is the requirement to include the
positional argument  in the 'volume snapshot create'
command.  Again what was implemented is not what was intended, and any
command that includes both the --volume argument and the snapshot name
will continue to work. The Backward Incompatible Changes doc[1] has
more details on these changes.
* A number of new Network API-based commands have been added, as this
is already longer than most will read see the 3.10.0 Release Notes for
details.[2]

## OSC Core Team

I am of mixed emotions in announcing a couple of core team changes:
Huanxuan Ao is leaving to focus on completing his thesis and Rui Chen
has been added. They both have been doing excellent work for some time
and we look forward to Rui joining the core team.  Huanxuan, thank you
very much, we appreciate all of your contributions to OSC and
OpenStack in general.

On a related note, OSC was affected pretty hard by the end of OSIC as
a number of the people implementing new Network and Volume commands
were impacted.  Much of what we added in this release was contributed
by that crew and we appreciate their contributions as well.  There
remains some unfinished work that we will sort out and re-prioritize
as we talk to the affected projects.  I plan to do some of that in
Boston next week.


If you have read this far, thank you.  I do not write a lot, and when
I do I seem to try to make up for that.

dt


[0] http://eavesdrop.openstack.org/#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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-14 Thread Dean Troyer
On Fri, Apr 14, 2017 at 7:12 PM, Rochelle Grober
<rochelle.gro...@huawei.com> wrote:
> Part 1: tldr; publish the resolutions to the key MLs at least when they are 
> approved.

This was done for a time via blog posts, I recall talk about
resurrecting that, this may help increate the priority of following up
on that thought.

> Part 2: tldr; establish some kind of communications channel with other 
> TCs/TSCs that have dependencies on OpenStack
>
> I just happened to be in a meeting with an associate who is on the TSC of 
> Open Daylight.  After the meeting he asked me about the release schedules of 
> OpenStack and whether the recent change was a one off or , would now be 
> offset like the last or.  It appears that ODL sets their releases to two 
> week after OpenStack's then other Open networking projects cascade behind 
> Open Daylight.  These TSCs don't know where to go to get the info/new 
> schedules, etc.  Itg might be nice to find out what they need from us and 
> provide a channel for them to ask questions.  TC might be a good contact 
> point.  But TC can certainly come up with possible solution(s).  Which could 
> open all these projects work a towards a more open coordination or 
> cooperation with us.  I think that would be sooo cool.

The TC could certainly be a point of contact, I think it would also be
appropriate to hook up individual members as these sorts of things are
discovered to establish relationships.  Often times the TC will
delegate one or a few people to be contact points for things like this
anyway.

Communication-wise, this seems to be to be the sort of thing -announce
mailing lists should be used for.  Going back a couple of weeks I see
our -announce list consists of a lot of release announcements for
individual deliverables and a couple of OSSA's.  I'm not trying to
resurrect the debate over what that list should be used for, but it
does seem like that might have been a place for those not involved in
our community on a daily basis to see those sorts of announcements go
by.  That said, the release schedule and info really is easy to find
via your favorite search: "openstack release schedule" on Google
results in a table with recent release dates appearing even before the
first search result, which happens to be
https://releases.openstack.org.  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 Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][elections]questions about one platform vision

2017-04-14 Thread Dean Troyer
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 charter:

[2] https://governance.openstack.org/uc/reference/charter.html

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc][elections]questions about one platform vision

2017-04-14 Thread Dean Troyer
On Fri, Apr 14, 2017 at 3:34 AM, Thierry Carrez <thie...@openstack.org> wrote:
> Like all analogies, this one is not perfect (in particular it horribly
> fails to capture the "open" nature of the stack), but I think it's still
> useful to inform on what OpenStack is.

On the other hand I do think it captures the common feeling of
stepping on them in the dark barefoot...

I think the fact that this question comes up over and over, almost
like clockwork, is a clear signal that we (the community overall)
still do not have a shared understanding of the answer, or some just
don't like the stated answer and their change process is repeating the
question hoping the answer changes.

We've used the term 'cloud operating system' in various places, but
not in our defining documents:

* The Bylaws[0] use the phrase "the open source cloud computing
project which is known as the OpenStack Project"
* The TC charter[1] uses the phrase "one community with one common
mission, producing one framework of collaborating components"
* The UC charter [2] does not include a statement on "what is OpenStack"

I've never liked the "cloud operating system" term because I felt it
mis-represented how we defined ourself, but I've come to realize it
may be the easiest-to-understand metaphor yet for what we are and
where we are today.  Going forward it is increasingly apparent that
hybrid stacks (constellations, etc) will be common that include
significant components that are not OpenStack at layers other than
"layer 0" (ie, below all OpenStack components: database, message
queue, etc).  The example commonly given is of course Kubernetes, but
there are others.

UNIX caught on as well as it did partly because of its well-defined
interfaces between components at user-visible levels, specifically in
userspace.  The 'everything is a file' metaphor, for all its faults,
was simple to understand and use, until it wasn't.  But to still
serves us well.  There was a LOT of 'differentiation' between the
eventual commercial implementations of UNIX which caused a lot of pain
for many (including me) but the masses have settled on the
highly-interoperable GNU/Linux combination. (I am conveniently
ignoring the still-present 'differentiation' that Linux distros insist
on because that will never go away).

[Thank you for reading this far, I didn't intend for this to be so
verbose, but airport terminals can be quite boring at times :) ]

This is where I see OpenStack today.  We are in the role of being the
cloud for the masses, used by both large (hi CERN!) and small (hi
mtrienish's closet!) clouds and largely interoperable.  Just as an OS
(operating system)is the enabling glue for applications to function
and communicate, our OS (OpenStack) is in position to do that for
cloud apps.  What we are lacking for guidance is a direct lineage to
20 years of history.  We have to have our own discipline to keep our
interfaces clean and easy to consume and understand, and present a
common foundation for applications to build on, including applications
that are themselves higher layers of an OS stack.

Phew!  Thank you again for reading this far, I know this is not news
to a lot of our community, but the assumption that "everyone knows
this" is not true, we need to occasionally repeat ourselves to remind
ourselves and inform our newer members what we are, where we are
headed and why we are all here in the first place: to enable awesome
work to build on our foundation, and if we sell a few boxes or 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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-12 Thread Dean Troyer
On Wed, Apr 12, 2017 at 4:07 AM, Thierry Carrez <thie...@openstack.org> wrote:
> One idea I've been considering is eliminating the one and only sacred
> one-hour weekly TC meeting, and encouraging ad-hoc discussions (on
> #openstack-dev for example) between change proposers and smaller groups
> of TC members present in the same timezone. That would give us a good
> feel of what everyone thinks, reduce noise, and happen at various times
> during the day on a public forum, giving an opportunity for more people
> to jump in the discussion. The informal nature of those discussions
> would make the governance reviews the clear focal point for coordination
> and final decision.

This sounds like a form of 'office hours' format, and I like the idea.
We could even try to get come semi-firm commitments from TC members to
be present at particular times (spread 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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Tacker][OSC] Command naming specs

2017-04-12 Thread Dean Troyer
On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi <trinath.soman...@nxp.com>
wrote:

> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
> prefix.
>

Note that OSC itself does not use 'command prefixes', it names resources
with enough specificity to make them unique.  Sometimes that looks like a
proefix, but it is not.

For the below commands, for readability, we have added ‘-‘ within the
> command names.
>
> Like,
>
>   network-service,  vnf-forwarding-graph, service-function-chain,
>
> network-flow-classifier, network-forwarding-path.
>
>
>
> But the existing OSC commands don’t have a ‘-‘ in between the command
> names.
>

The OSC command structure specifically does not use dashes or underscores
as separators, it uses spaces.  We want commands to be words.  Dashes are
only used in option names due to option parsing rules.

Specifically in networking there are a large number of resources that are
hard to concisely name.  Plugins are of course free to do what they want
but we encourage them to use the OSC guidelines, and we know that users
_really_ appreciate staying consistent.

There are places where you may feel forced to use abbreviations ('vnf' in
your example above).  Those are discouraged, but we also recognize that
they are often the most common usage ('IP' in IP address for example) and
where that usage is common is fine.  Again, networking is an area where
many things are commonly 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-10 Thread Dean Troyer
On Mon, Apr 10, 2017 at 1:52 PM, Matt Riedemann <mriede...@gmail.com> wrote:
> How will the TC grow a diverse membership if it's not even held, at least
> every other week, in a timezone where the other half of the world can
> attend?

This is something we do need to sort out. The experiences I have seen
with a number of other meetings that do the alternating time is you
mostly get attendees showing up during their 'local' time slot. This
of course is not how the TC operates, requiring a quorum, and holding
in-meeting votes at times.  I do think that my experience is not
representative of meetings attended by elected members.  Also, we
already ask our close-to-UTC-TZ members to give up evening time
(family time for many) for the meetings.  It might be worthwhile to
look at more than two times for alternation.

There is an additional question around language.  The board has seen
where some members may not be comfortable in a non-native language
meeting and may not speak up like they might otherwise.  The current
board makeup is such that regional meetings (not official board
meetings) in Chinese have become feasible and the feedback is that the
participation is much greater for those in attendance.

The TC meetings are held in IRC and that may somewhat mitigate the
issue for non-native English speakers, but I've had problems myself
keeping up at times with the flurry of comments.  In any case, I think
it would be good to include language in the pile of concerns 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
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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Dean Troyer
On Mon, Apr 10, 2017 at 10:19 AM, Matt Riedemann <mriede...@gmail.com> wrote:
> How long are we expected to be carrying this deprecated bridge code? If you
> need these CLIs/API bindings in the client, then don't upgrade to 8.0.0, or
> run different versions of novaclient in venvs or containers if you need to
> really workaround this.

Oh how I wish this were as easy in practice as it sounds.

> I feel like the signaling on all of this was pretty clear back in Newton.
> What else are people expecting or that we missed? I don't really see why
> python-openstackclient needs to start adding this API binding code back in
> locally, that's just extending the lifespan of this busted code that we're
> really trying to make uncomfortable for people to be using because like it
> or not, nova-network is going away. We did the fallback thing in the CLI in
> newton as a way to soften that blow for CLI users, but really at some point
> this just needs to be broken and people either stay on old tools or upgrade
> to what is supported.

Matt, I am not questioning the signalling nor the actual removal, that
is the right thing for novaclient at some point.  I did miss the early
indications of the timing of 8.0, only seeing it two weeks before the
release, but that is on me.

The fact that this causes us problems is not your problem, but
highlights why OSC and Shade and other things really do not want to
use the project clients because the use cases and assumptions and
other things are different.  I started 3 years ago to start replacing
those things, the SDK came long to replace that work but is still not
at a 1.0 release.  So I'm playing catch-up.

Upgrading old nova-net clouds has been deemed impossible, which is why
we don't do it.  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 Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] [elections] Available time and top priority

2017-04-10 Thread Dean Troyer
On Mon, Apr 10, 2017 at 4:16 AM, Thierry Carrez <thie...@openstack.org> wrote:
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ? If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

In the last six months of my abbreviated term on the TC I was able to
increase the amount of time I was able to spend on TC work, and most
of that time went toward the work for additional language supprot, and
specifically golang support with the creation of the Golang Consistent
Testing Interface.

I plan to continue that work whether I am re-elected to the TC or not.
There has been a lot of concern expressed regarding the community
impact of any alternate languages.  Specific experiences with projects
that have already been down that path (eg Horizon with Javascript)
indicate that these concerns can not be ignored.  Part of the
challenge is to not create a situation where the resulting
multi-language environment is totally foreign to any of the
communities involved.  We already have some of that problem in
OpenStack with the broader Python community (I'm looking at you, pbr),
I want to work to minimize that for the new environments and their
existing communities, but also for an OpenStack developer to feel
comfortable and for OpenStack practices to be as consistent as
possible to minimize the pain of moving among our projects.  This is a
tricky proposition but is even trickier without conscious and
intentional coordination.

Some of my other priorities for the TC include refining OpenStack's
identity and focus as we continue to 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 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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 Thread Dean Troyer
On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki <amot...@gmail.com> wrote:
> (question not directly related to this topic)
> I am not sure there is a case where users still use API 2.36 for
> network management
> and newer API versions for other compute operation.

This is probably true for Horizon, where the app install likely
matches the cloud it is configured to use.  However, many other use
cases for the Python libraries are meant to talk to multiple versions
of clouds and the 8.0 release of novaclient causes problems there.

Even after nova-net support is EOL officially OSC plans to support the
use of nova-net for some time.  We are re-implementing the removed
functionality locally.  And anticipating some of the questions why,
consider an operator working on the long migration/upgrade from a
deployed nova-net cloud to a Neutron cloud, and needing to keep at
least 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?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [election][tc] TC candidacy

2017-04-05 Thread Dean Troyer
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 and the explosive growth we experienced in our early years
has subsided.  As a community, we threw a lot of things against the
wall to see what would stick, and those answers are continuing to
become evident.  In come cases we can re-affirm the direction taken,
in others it has been time wrap up and move on.  All of which is a
long-winded way to say we have already begun making some hard
decisions about projects and future and direction.

The TC has begun a process of defining a vision[0] of where we want to
be by describing the OpenStack world as we see it in two years.  One
big part of that vision involved how we operate in the world around
us, ie, other related-but-not-OpenStack projects in the Open Source
cloud world.  We have already seen a good amount of time and effort
expended by OpenStack community members getting involved with other
projects such as Kubernetes and vendor-related products like
OpenShift.  It is imperative that we position ourselves to complement
and not compete with others in our greater community.

And yes, I am going exactly where most of you thought I was with this.
In recent months the TC has taken steps to define how languages that
are not Python might be used in OpenStack projects.  The language
addition process[1] was approved, the first use case analysis to use
Golang team was approved[2], a golang test inteface (CTI) has been
approved[3] and work is underway for implementing the required support
in our CI to test golang projects at the scale we need.

The world around us has changed and OpenStack needs to continue to
grow and adapt with it.  This is an important priority for me, having
written and prototyped the golang CTI.  OpenStack does not need to own
and control everything about building and deploying clouds, but there
are some critical things that we do need to keep close tabs on for the
sake of our deployers and users.  I am excited about some of the
things the OpenStack Foundation staff are working on with regards to
our external relationships, some of which is already visible in the
Boston Summit promotion.

I would be honored to continue serving the community on the Technical Committee.

Thank you
dt


[0] The first draft that came out of our session last month:
https://review.openstack.org/453262
[1] 
https://governance.openstack.org/tc/reference/new-language-requirements.html#step-1-use-case-analysis
[2] 
https://governance.openstack.org/tc/resolutions/20170329-golang-use-case.html
[3] https://governance.openstack.org/tc/reference/cti/golang_cti.html

-- 

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

2017-03-20 Thread Dean Troyer
On Mon, Mar 20, 2017 at 5:52 PM, Monty Taylor <mord...@inaugust.com> wrote:
>> [Hongbin Lu]
>> I think the style would be more consistent if all the resources are 
>> qualified or un-qualified, not the mix of both.

> So - swift got here first, it wins, it gets container. The fine folks in
> barbican, rather than calling a thing a container and then needing to
> call it a secret-container - maybe could call their thing a vault or a
> locker or a safe or a lockbox or an oubliette. (for instance)

Right, there _were_ only 5 projects when we started this and we
re-used most of the original project-specific names.  Swift is a
particularly fun one because both 'container' and 'object' are
extrement useful in that context, but both are also extremely generic,
and 'object container', well, what is that?

> I do not have any suggestions for things that actually return a resource
> that are a single "linux container" - since swift called their thing a
> container before docker was written and popularized the word to mean
> something different. We might just get to be fun and different - sort of
> like how Emacs calls cut/paste "kill" and "yank" (if you're not an Emacs
> user, you "kill" text into the kill ring and then you "yank" from the
> ring into the current document.

Monty, grab your Tardis and follow me around the Austin summit and
listen to the opinions I get for doing things like this :)

> OTOH, I think Dean has talked about more verbose terms and then aliases
> for backwards compat. So maybe a swift container is always an
> "object_container" - but because of history it gets to also be
> unqualified "container" - but then we could have "object container" and
> "secret container" and "linux container" ... similarly we could have
> "server flavor" and "volume flavor" ... etc.

Yes, we do have plans to go back and qualify some of these resource
names to be consistent, 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 flavor'.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

2017-03-20 Thread Dean Troyer
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.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [magnum][osc] What name to use for magnum commands in osc?

2017-03-20 Thread Dean Troyer
On Mon, Mar 20, 2017 at 3:37 PM, Adrian Otto <adrian.o...@rackspace.com> wrote:
> the  argument is actually the service name, such as “ec2”. This is 
> the same way the openstack cli works. Perhaps there is another tool that you 
> are referring to. Have I misunderstood something?

I am going to jump in here and clarify one thing.  OSC does not do
project namespacing, or any other sort of namespacing for its resource
names.  It uses qualified resource names (fully-qualified even?).  In
some cases this results in something that looks a lot like
namespacing, but it isn't. The Volume API commands are one example of
this, nearly every resource there includes the word 'volume' but not
because that is the API name, it is because that is the correct name
for those resources ('volume backup', etc).

> We could so the same thing and use the text “container_infra”, but we felt 
> that might be burdensome for interactive use and wanted to find something 
> shorter that would still make sense.

Naming resources is hard to get right.  Here's my throught process:

For OSC, start with how to describe the specific 'thing' being
manipulated.  In this case, it is some kind of cluster.  In the list
you posted in the first email, 'coe cluster' seems to be the best
option.  I think 'coe' is acceptable as an abbreviation (we usually do
not use them) because that is a specific term used in the field and
satisfies the 'what kind of cluster?' question.  No underscores
please, 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?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [lbaas][neutron] Is possible the lbaas commands are missing completely from openstack cli ?

2017-03-17 Thread Dean Troyer
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.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][ironic] Kubernetes-based long running processes

2017-03-16 Thread Dean Troyer
On Wed, Mar 15, 2017 at 5:28 PM, Taryma, Joanna <joanna.tar...@intel.com> wrote:
> I’m reaching out to you to ask if you’re aware of any other use cases that
> could leverage such solution. If there’s a need for it in other project, it
> may be a good idea to implement this in some sort of a common place.

Before implementing something new it would be a good exercise to have
a look at the other existing ways to run VMs and containers already in
the OpenStack ecosystem.  Service VMs are a thing, and projects like
Octavia are built around running inside the existing 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 usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

2017-02-27 Thread Dean Troyer
On Mon, Feb 27, 2017 at 11:35 AM, Clint Byrum <cl...@fewbar.com> wrote:
> Thanks for your reply. The proposed change is meant to benefit
> readers of openstack-dev who do not have access to, or ability with,
> sup/procmail/sieve/IMAP/etc., but do want to be able to be able to keep
> up with the general flow of discussion in openstack-dev.

FWIW, I'm using GMail, and nothing else, to achieve acceptable
filtering/sorting _for me_.  But then I am interested in at least
seeing subjects of the wider community go past and not doing sharp
filtering on specific projects.

> The idea would simply be that those directly involved in a team wouldn't
> mind subscribing to a few more ML's to get relevant information about
> the day to day workings of a team, but that for most people openstack-dev
> would be sufficient.

This makes assumptions about who wants to see those messages intended
for the additional lists.

> So, I'll ask more generally: do you believe that the single openstack-dev
> mailing list is working fine and we should change nothing? If not, what
> problems has it created for you?

It is working about as well as can be expected _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.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

2017-02-27 Thread Dean Troyer
On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum <cl...@fewbar.com> wrote:
> This is not for users who only want to see some projects. That is a well
> understood space and the mailman filtering does handle it. This is for
> those who want to monitor the overall health of the community, address
> issues with cross-project specs, or participate in so many projects it
> makes little sense to spend time filtering.

Monday morning and the caffiene is just beginning to reach my brain,
but this seems counter-intuitive to me.  I consider myself someone who
_does_ want to keep in touch with the majority of the community, and
breaking things into N additional mailing lists makes that harder, not
easier.  I _do_ include core team updates, mascots, social meetings in
that set of things to pay a little attention to here, especially
around summit/PTG/Forum/etc times.

I've seen a couple 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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

2017-02-18 Thread Dean Troyer
On Sat, Feb 18, 2017 at 10:23 AM, Clint Byrum <cl...@fewbar.com> wrote:
> But I believe Michael is not saying "it's unsafe to read the json
> files" but rather "it's unsafe to read the whole config drive". It's
> an ISO filesystem, so you can't write to it. You have to read the whole
> contents back into a directory and regenerate it. I'm guessing Michael
> is concerned that there is some danger in doing this, though I can't
> imagine what it is.

Nova can be configured for config drive to be a VFAT filesystem, which
can not be trusted.  Unfortunately 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 than passwords in the
database.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

2017-02-18 Thread Dean Troyer
On Sat, Feb 18, 2017 at 7:11 AM, Artom Lifshitz <alifs...@redhat.com> wrote:
> In reply to Michael:
> I hadn't even thought of the security implication. That's a very good
> point, there's no way to persist admin_pass in securely. We'll have to
> read it at some point, so no amount of encryption will change
> anything. We can argue that since we already store admin_pass on the
> config drive, storing it in the database as well is OK (it's probably
> immediately changed anyways), but there's a difference between having
> it in a file on a single compute node, and in the database accessible
> by the entire deployment.

Honestly I don't think a policy of "admin password is only available
on first boot (initial config drive)" is a bad one.  Any workflow that
does not change that password immediately is broken security-wise, and
I see no reason for us to enable that sort of workflow to get worse by
extending the availability of that initial password.

We do not break existing users by ignoring the admin password on
subsequent config drive images.  Of course I can always be
misunderestimating the "innovation" of users making use 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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

2017-02-16 Thread Dean Troyer
On Thu, Feb 16, 2017 at 7:54 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
> It seems like a lot of people view "developing OpenStack" as more
> attractive than "making it easy to deploy OpenStack" (via the
> deployment tools in the tent). Doing both is really something project
> teams should do, but I don't think shoving all of the deployment
> tooling in repo makes that any better frankly. If we put our tooling
> in repo, we'll likely then start collecting RPM/Debian/etc. packaging
> in repo as well.

Part of it _is_ the "deployment isn't shiny/new/features", but there
is also the historical view lingering that we ship tarballs (and
realistically, git repo tags) so as not to pick favorites and to keep
deployment and packaging out of the project repos directly.

We have >5 different tools that are "mainstream" to consider, not even
the large project teams have enough expertise to maintain those.  I
had a hard enough time myself keeping both rpm and apt up to date in
previous projects, much less recipies, playbooks and the odd shell
script.

It is also hard to come in to a community and demand that other
projects suddenly have to support your project just because you showed
up.  (This works both ways, when we add a "Big Tent" project, now all
of the downstreams are expected to suddenly add it.)

The solution I see is to have a mechanism by which important things
can be communicated from the project developers that can be consumed
by the packager/deployer community.  Today, however sub-optimal it
seems to be, that is release notes.  Maybe adding a specific section
for packaging would be helpful, but in practice that adds one more
thing to remember to write to a list that is already hard to get devs
to do.

Ad Doug mentions elsewhere in this thread, the liaison approach has
worked in other areas, it may be a useful approach here.  But I know
as the PTL of a very small project I do not want 5 more hats to wear.
Maybe one.

We have encouraged the packaging groups to work together in the past,
with mixed results, but it seems to me that a lot of the things that
need to be discovered and learned in new releases will be similar for
all of the downstream consumers.  Maybe if that downstream community
could reach a critical mass and suggest a single common way to
communicate the deployment considerations in a release it would get
more traction.  And a single project liaison for the collective rather
than one for each deployment project.

> I think what would help improve willing bidirectional communication
> between service and deployment/packaging teams would be an
> understanding that without the deployment/packaging teams, the service
> teams will likely be out of a job. People will/can not deploy
> OpenStack without the tooling these other teams provide.

True in a literal sense.  This is also true for our users, without
them nobody will deploy a cloud in the first place.  That has not
changed anything unfortunately, we still regularly give our users
miserable experiences because it is too much effort to participate
with the (now comatose) UX team or prioritize making a common log
format or reduce the number of knobs available to twiddle to make each
cloud a unique snowflake.

We can not sustain being all things to all people.  Given the
contraction of investment being considered and implemented by many of
our foundation member companies, we will have to make some hard
decisions about where to spend the resources we have left.  Some of
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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

2017-02-16 Thread Dean Troyer
On Thu, Feb 16, 2017 at 7:06 AM, Andrey Kurilin <akuri...@mirantis.com> wrote:
> Yes, I forgot about it. But it changes nothing.
> Custom implementation of particular service should cover the same API as an
> official one. For me, as for user, it doesn't metter if there is Keystone or
> MyAwesomeKeystone, I want just an service which implements Keystone
> functionality.

Actually it is the name field that we really do not need, nor want.
Its continued existence is mostly driven by a desire by deployers to
brand their services, nothing should currently be using to as a
selector.  The type field is what (should be) used in places like the
base URL for services under a combined endpoint (ie,
host/compute/v2.1/...) on a single port.  For any alternate
implementations of a service that a deployer wants to take the place
of an OpenStack service this is how that is done 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...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [octavia][sdk] service name for octavia

2017-02-14 Thread Dean Troyer
On Tue, Feb 14, 2017 at 7:08 PM, Qiming Teng <teng...@linux.vnet.ibm.com> wrote:
> When reviewing a recent patch that adds openstacksdk support to octavia,
> I found that octavia is using 'octavia' as its service name instead of
> 'loadbalancing' or 'loadbalancingv2' or something similar.

The service name is actually irrelevant from a technical point of
view. It is maintained for deployer configuration and is often used
just for branding purposes.  It is the service type that should
uniquely identify a service in the catalog.

> The overall suggestion is to use a word/phrase that indicates what a
> service do instead of the name of the project providing that service.

Correct, this is the service type.

> [2] Octavia service naming:
> http://git.openstack.org/cgit/openstack/octavia/tree/devstack/plugin.sh#n52

This points to Octavia's DevStack 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-types-authority

-- 

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] Large Contributing OpenStack Operators working group?

2017-02-03 Thread Dean Troyer
On Fri, Feb 3, 2017 at 8:28 AM, Sean M. Collins <s...@coreitpro.com> wrote:
> I suppose I am also philosophically opposed to having all these special
> snowflake working groups. If you want to get things done in OpenStack
> the best thing to do is roll up your sleeves and start participating
> directly in the project where you need work done. I know for a fact that
> in the Neutron community, we had RFE bugs and other processes so that
> operators could submit requirements, and they weren't expected to do all
> the work by themselves.

I read through the LCOO[0] etherpad meeting notes last night and it
does appear that this group is bringing some resources to "do work",
there was a 2 FTE per member requirement initially.  From reading the
notes I got the feel of a very corporate-style project in that there
is still a lot of planning and organizing going on but there were
notes pointing to things being proposed and merged into existing
projects in addition to the aspirations of new ones.

My primary concern in this instance is the model being used here.  The
members of the group want to control the scope (approval to add a
topic) and membership (justification and approval of members).  Often
this is done to prevent scope creep and maintaining focus.  But it
contrary to the founding principles of OpenStack.  The notes talked
about getting Foundation buy-in but I didn't see anything of the
outcomes of that.

LCOO also appears to be a collection of companies that have brought
some internal projects out into the twilight (searching for sunlight?)
and looking for a way to upstream that work.  Even today many
companies that have names familiar in the Open Source/Free Software
world struggle with how to actually operate in this world.  We need to
help them, both from the community side and from within.

I do think there needs to be a lot of encouragement for LCOO and other
groups that are actually more like trade associations to fully commit
to an open development model, specifically OpenStack's established
model since there is an explicit desire for their work product to be
included in OpenStack directly. They will greatly benefit form
starting out in our development and operation style.

[[There is another entirely separate subject regarding the direction
that LCOO wants to go and the sustainability in making a single
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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron] [release] misleading release notes

2017-02-02 Thread Dean Troyer
On Thu, Feb 2, 2017 at 7:42 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> As long as the edit happens on the branch where the note should appear,
> it should be fine.

Excellent!  Just tried it and it does, thanks.

I think https://review.openstack.org/427842 is doing what you intend,
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.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron] [release] misleading release notes

2017-02-01 Thread Dean Troyer
On Wed, Feb 1, 2017 at 8:13 PM, Armando M. <arma...@gmail.com> wrote:
> I suspect what happens is that someone revises the content at a later date
> and reno associated the last timestamp of the release note with release
> where the change has been made?

I do believe this is the case, reno puts a note in the release that it
find it in, thus editing notes after branching is going to give you
the result you so not want.

I've made a point to do one last relnote cleanup pass before releases
to catch the errors/typos that have slipped through, but OSC doesn't
have near the volume 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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][openstackclient][glance] broken image functional test

2017-01-20 Thread Dean Troyer
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 image
> change and should show the v1 breakage.  As is often heard, "it's
> working for me that way in DevStack" :)

For completeness, Ian fixed the problem and added a functional test
[0] that also passes my little canary unit tests [1].  The revert has
been abandoned.

Ian & Brian, thanks for jumping on this quickly.

dt

[0] https://review.openstack.org/#/c/423499/
[1] https://review.openstack.org/423345


-- 

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][openstackclient][glance] broken image functional test

2017-01-20 Thread Dean Troyer
On Fri, Jan 20, 2017 at 10:00 AM, Brian Rosmaita
<rosmaita.foss...@gmail.com> wrote:
> We've approved the revert to get the OSC unblocked, though it may be a
> while before jenkins gets around to processing it, as (of course) the
> gate is pretty busy now.

Thanks Brian.  This is our last week before the freeze and we're
trying to fix our own upstream-breakage before then.

> Even with sufficient caffeine, it's not obvious.  We didn't change the
> v1 API for this (translation for v1 is being handled in the registry),
> and the v1 test coverage is pretty good, so it looked like nothing was
> broken.  On a closer look, the relevant v1 tests for this particular
> problem check the response code, not the actual response content, so we
> will beef those up a bit.

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 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.openstack.org/423345

-- 

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][openstackclient][glance] broken image functional test

2017-01-20 Thread Dean Troyer
On Fri, Jan 20, 2017 at 6:46 AM, Steve Martinelli
<s.martine...@gmail.com> wrote:
> it seems the OSC gate is broken, several patches are failing the same way:

[...]

> did something break? at first glance (hehe), it seems this patch may be to
> blame?
> https://github.com/openstack/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_CAFFIENE.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] Consistent Versioned Endpoints

2017-01-12 Thread Dean Troyer
On Thu, Jan 12, 2017 at 12:35 PM, Scott D'Angelo
<scott.dang...@gmail.com> wrote:
> Can we get to this "perfect world"? Let's discuss at the PTG.
> It is my understanding that we do not have the ability to schedule a time or
> room for such a cross-project 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

-- 

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-20 Thread Dean Troyer
On Tue, Dec 20, 2016 at 3:39 PM, Clay Gerrard <clay.gerr...@gmail.com> wrote:
> http://docs.openstack.org/developer/python-openstackclient/command-list.html


> The collision of top-level resource names is not new.  You see stuff like
> "volume create" & "server create" - but also "volume backup create" &
> "server backup create"- which is an obvious pattern to replicate for
> disambiguating top level name conflicts with similarly named
> (sub?)-resources between services - except apparently in an effort to keep
> things flat no one saw it coming with a name like "container".

This is exactly how it should work.  I do want to make an additional
important but subtle point:  while it looks like those are namespaced
commands, we used 'server' not 'compute' because it is not a
compute-namespaced, but a server-specific resource.

> But IMHO an object-store "container" is not a top level OpenStack resource,
> is it?  I would think users would be happy to dump stuff into the object
> store using "object create" - and reasonably expect to use "object container
> create" to create a container *for their objects*?  This isn't a generic
> OpenStack "container" - you can't use this generic "container" for anything
> except objects?  Oddly, this pattern is already in use with the pre-existing
> "object store account" command?!

'object store account' is a hack that I still hate, but due to Swift's
unique ability to not use Keystone we had to do something.  'object
store container' would be consistent, 'object store object' is awful.

> Is it really already too late to apply some sane organization to the object
> store commands in the openstack-cli and make room in the command namespace
> for a top level OpenStack resource to manage a linux-containers' service?
> Because of backwards compatibility issues?

Notice that in the command list lined above the 'backup' resource has
been deprecated and renamed 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 renaming
these resources takes a long time to complete.  Freeing up the
top-level bare container resource would be three cycles out at best.

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/mailman/listinfo/openstack-dev


Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

2016-12-20 Thread Dean Troyer
On Tue, Dec 20, 2016 at 3:00 PM, Hongbin Lu <hongbin...@huawei.com> wrote:
> In the long-term, I am going to propose to follow the style of AWS CLI, that
> is prefixing each command with a project name. For example:

We have been down this particular path multiple times, and this is not
how the OSC commands work.  Some plugins have already chosen to
'namespace' their commands, which I think is a bad idea, rather than
use specific descriptive names for their resources.  The vast majority
of plugins have managed to find specific descriptive names.

You should also please keep in mind that resources should be named
from the point of view of the OSC user, not an OpenStack developer.
The implementation of the service often has no meaning to CLI users so
you want to consider what they will be looking for first.

Honestly I think the word 'container' is already so overused, and 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Golang technical requirements

2016-12-14 Thread Dean Troyer
On Wed, Dec 14, 2016 at 7:46 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> FWIW, some of the deployment tool communities (ansible and puppet,
> I think) rely on git repos without external artifacts, and we're
> supporting them in our release tools today. I'm not sure how
> downstream packagers feel about the lack of external artifacts.

I recall zigo working hard for the Debian packaging to come strictly
from Git repo tags but do not recall seeing opinions from other
packagers.

> Were you thinking of files other than the tarball when you say
> "generated 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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Golang technical requirements

2016-12-14 Thread Dean Troyer
On Wed, Dec 14, 2016 at 4:25 AM, Thierry Carrez <thie...@openstack.org> wrote:
> I don't think we need to stop producing and publishing source code
> tarballs in the Go case, just because it's not the primary way people
> consume the code. Publication of the source code is something we need to
> do as part of the open source license we use, and some still consider
> tarball publication to be a clearer form of "publication" than keeping a
> git server up.

I'll buy that.  Overall, I don't think we are doing anything today
that is incompatible with what I see golang needing.  This is really a
side-issue that I have heard you, and maybe others, ask about in
general, so I included it to affirm the golang case. Making changes to
the general case is separate in my mind, but this may be a good time
to consider it in parallel since we're thinking about these things
again in detail.

> Beyond the source though, one question is whether we should build, sign
> and distribute binary artifacts (compiled code), or if tagging a source
> repo (and producing a source code tarball) is sufficient. And if we do
> distribute binaries, would we only do that for some deliverables (like
> the top ones that are supposed to be directly used by users) or for
> everything ?

I am not in favor of distributing binaries as a matter of course,
although from a purely selfish point of view I want the ability to do
that for a future CLI binary for Windows.  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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Golang technical requirements

2016-12-13 Thread Dean Troyer
On Tue, Dec 13, 2016 at 4:26 PM, Jay Pipes <jaypi...@gmail.com> wrote:
> Not sure if it's already been brought up, but I really like govendor:

Govendor and glide are the two most promising candidates at this
point.  I just read today's summary of the Package Management
Committee [0] and that sounds _really_ promising, if further out than
we can wait on, but there will be migration paths from many of the
existing tools.  Both govendor and glide have devs in the Advisory
Group to the committee.

> More than the decision between dependency management toolkits, though, is
> the decision over whether to have *any* vendored source code in the primary
> project's source tree itself (as opposed to only storing the
> vendor.json/glide.yaml|lock file that lists dependent library versions and
> locations). Please let's have a policy of keeping vendored source code *out*
> of the primary project source tree.

This is the intention and I see no reason why it is not achievable.
It totally depends (ha!) on having better (any!) dependency management
in place.

One thing that I have been pondering is resurrecting the old technique
of embedding version info into binaries so they can be examined to
discover which library versions were used in its build.  This was
totally a thing when I was using rcs ($Id$ and ident(1) FTW) but that
particular technique is messy with distributed version control, and
may not be needed at all in a packaged distro environment.  This 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 Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Golang technical requirements

2016-12-13 Thread Dean Troyer
I am working on scoping the tasks required for the technical pieces of
Golang adoption in OpenStack.  This work has been informed somewhat by
flaper87's reference doc proposal[0] for new language additions and is
(mostly) compatible with it, pending that proposal's final approval by
the TC.

As a first step, I proposed a Common Testing Interface (CTI)
document[1] for Go.  There is, of course, much more than this,
including a number of significant decisions that still need to be
made.  At this point I want to focus on identifying those decisions
and other tasks rather than solving them immediately.

Some of the previous work done around using Golang in OpenStack has
been collected in an Etherpad[2] and summarized into major categories.
I am confident that I have not found everything that has been done and
would appreciate pointers to whatever resources you may have.  Here
are some highlights of areas that still require discussion and
decisions:


Common Libraries

flaper87's reference doc touches on project requirements for new
languages and Oslo-compatible implementations.  At the time of this
writing this is not yet finalized, with some discussion around how
much to require, and if the first project to utilize a new language
should shoulder all of the burden of also implementing those
libraries.


Dependency Management

There are a number of tools available for Golang to manage
dependencies.  A number have been evaluated already with a couple of
strong contenders identified.  Once a tool is selected, process needs
to be set up to track dependencies and versions tested.


Release Deliverables

OpenStack still officially considers the tarballs generated during the
release rpocess to be our official deliverable.  Many downstream
consumers, however, bypass those and go directly to the tagged
releases in the Git repos.  The Golang community has no real culture
of using tarballs at all, given the 'go get' functionality bult in to
the tooling directly for checking out remote repos.  One obvious
shortcoming in just defining the release to be Git repo tags is our
use of generated files.


If you have an interest in seeing Golang support implemented for
OpenStack, please jump in here and help us nail down how to accomplish
that "right".

dt

[0] https://review.openstack.org/#/c/398875/
[1] https://review.openstack.org/410355
[2] https://etherpad.openstack.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.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2016-11-22 Thread Dean Troyer
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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2016-11-21 Thread Dean Troyer
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 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/mailman/listinfo/openstack-dev


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

2016-11-18 Thread Dean Troyer
> -Original Message-
> From: Luke Hinds <lhi...@redhat.com>
[...]
>> for non security related functions, but when it comes to government
>> compliance and running OpenStack on public clouds (and even private for the
>> Telcos / NFV), not meeting FIPS will in some cases block production getting
>> a green light, or at least make it a big challenge to push through.

Are there any know cases of this happening?  If so, can those be
publicly documented to quantify how much this issue is hurting
deployments?



On Fri, Nov 18, 2016 at 9:57 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
> Also, instead of creating bugs, I would suggest instead that we try to make 
> this into a community goal. We would work with the TC and for P or Q, make it 
> a goal to start migrating off of MD5 and have a goal for a cycle or two later 
> to completely remove reliance on MD5.
>
> Doing this piecemeal via bugs will not be efficient and we'll need community 
> buy-in.

We would also need to get a reasonable scoping of the issue (which
projects, how many instances, etc) to help decide if this is an
achievable goal (in the sense 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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2016-11-17 Thread Dean Troyer
On Thu, Nov 17, 2016 at 4:55 AM, Sławek Kapłoński <sla...@kaplonski.pl> wrote:
> Thx all of You for explanations. So I think that [1] can be closed as
> "Won't fix" now. Am I right?
>
> [1] https://bugs.launchpad.net/neutron/+bug/1640767

Maybe?  Doug, Monty and I are talking 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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2016-11-16 Thread Dean Troyer
> Excerpts from Sławek Kapłoński's message of 2016-11-16 22:36:41 +0100:
>> Hello,
>> So I want to ask all of You how in Your opinion it should be solved.
>> Currently there is inconsistency between CLI clients and
>> API/Horizon/Openstack SDK (I checked that it is possible to create
>> resource without name via SDK).

There are a number of intentional inconsistencies between OSC and the
various REST APIs, precisely because many of the the APIs themselves
are very inconsistent not only between projects but even within each
project.  When those APIs are directly reflected in the CLI, like
happens with many of the project-specific CLIs, the users suffer due
to the inconsistencies.


On Wed, Nov 16, 2016 at 4:03 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> The OpenStackClient team made the decision to always require names
> for newly created resources. Perhaps Dean or Steve can fill in more
> of the background, but my understanding is that this is a design
> decision for the user interface implemented by OSC, and not is not
> considered a bug.

Doug is correct here, we (OpenStackClient) made a specific decision in
the command structure to always use the resource name as the
positional argument of a create command.  In this case I believe the
consistency is worth what pain it may cause to invent a name for a new
policy.

We have done UX surveys with OSC at the last two summits and the
number one favorable comment from 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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


  1   2   3   4   >