Re: [openstack-dev] [all] Naming the T release of OpenStack

2018-10-18 Thread Ed Leafe
On Oct 18, 2018, at 11:43 AM, Michał Dulko  wrote:
> 
> I'm totally supportive for OpenStack Train, but got to say that
> OpenStack Troublesome is a wonderful name as well. :)

Yeah, I’m sure that the marketing people won’t have a problem vetting that 
name. :)

-- Ed Leafe






__
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] [tc] [api] Paste Maintenance

2018-10-15 Thread Ed Leafe
On Oct 15, 2018, at 7:40 AM, Chris Dent  wrote:
> 
> I'd like some input from the community on how we'd like this to go.

I would say it depends on the long-term plans for paste. Are we planning on 
weaning ourselves off of paste, and simply need to maintain it until that can 
be completed, or are we planning on encouraging its use?


-- Ed Leafe






__
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] [placement] The "intended purpose" of traits

2018-09-29 Thread Ed Leafe
On Sep 28, 2018, at 12:19 PM, Chris Dent  wrote:
> 
> I don't think placement should be concerned about temporal aspects
> of traits. If we can't write a web service that can handle setting
> lots of traits every second of every day, we should go home. If
> clients of placement want to set weird traits, more power to them.
> 
> However, if clients of placement (such as nova) which are being the
> orchestrator of resource providers manipulated by multiple systems
> (neutron, cinder, ironic, cyborg, etc) wish to set some constraints
> on how and what traits can do and mean, then that is up to them.

This.

It is up to the clients to determine how to use Placement. But it is up to 
Placement to give guidance as to how to best use it. If a client wants to hack 
trait names, then they certainly can, and it might work out just fine.

> On Sep 28, 2018, at 8:25 AM, Eric Fried  wrote:
> 
> Bubble wrap was originally intended as a textured wallpaper and a
> greenhouse insulator. Can we accept the fact that traits have (many,
> many) uses beyond marking capabilities, and quit with the arbitrary
> restrictions?

The crux here is what one considers "arbitrary". If we as a project state 
"sure, go ahead and use this however you like", we are going to be complicit in 
the technical debt they accumulate, as Jay has referenced with regards to 
Nova's ComputeCapabilities filter.

We want consumers of Placement to write good, solid code that doesn't encourage 
technical debt accumulation. We have no way to prevent bad decisions by others, 
but we should never document that such usages are fine.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [placement] The "intended purpose" of traits

2018-09-29 Thread Ed Leafe
On Sep 29, 2018, at 10:40 AM, Jay Pipes  wrote:
> 
>> So here it is. Two of the top influencers in placement, one saying we
>> shouldn't overload traits, the other saying we shouldn't add a primitive
>> that would obviate the need for that. Historically, this kind of
>> disagreement seems to result in an impasse: neither thing happens and
>> those who would benefit are forced to find a workaround or punt.
>> Frankly, I don't particularly care which way we go; I just want to be
>> able to do the things.
> 
> I don't think that's a fair statement. You absolutely *do* care which way we 
> go. You want to encode multiple bits of information into a trait string -- 
> such as "PCI_ADDRESS_01_AB_23_CD" -- and leave it up to the caller to have to 
> understand that this trait string has multiple bits of information encoded in 
> it (the fact that it's a PCI device and that the PCI device is at 
> 01_AB_23_CD).
> 
> You don't see a problem encoding these variants inside a string. Chris 
> doesn't either.
> 
> I *do* see a problem with it, based on my experience in Nova where this kind 
> of thing leads to ugly, unmaintainable, and incomprehensible code as I have 
> pointed to in previous responses.

I think that there is huge difference between the Placement service stating 
"this is how you use this service" and actively preventing others from doing 
dumb things with Placement. If we, as a team, tell others that it is OK to 
manage state, or use a trait name to encode multiple bits of information, then 
others will be more likely to do just that, and end up with an unreadable mess 
around their part of the code that works with placement. The result will be a 
perception among others along the lines of "placement sucks". If we state 
clearly that this is not a good way to work with Placement, and they do so 
anyway, well, that's on them.

So we shouldn't enforce anything about trait names except the custom namespace 
and the length. If other service want to be overly clever and try to overload a 
trait name, it's up to them to deal with the resulting mess. But in no way 
should we *ever* encourage, even tacitly, this approach.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [all][api] POST /api-sig/news

2018-09-20 Thread Ed Leafe
Greetings OpenStack community,

This newsletter is very different than the past few, in that there is some 
actual news.

We, as a SIG, have recognized that we have moved into a new phase. With most of 
the API guidelines that we needed to write having been written, there is not 
"new stuff" to make demands on our time. In recognition of this, we are 
changing how we will work.

Next Thursday, Sept 27, will be our last formal IRC meeting [7] in 
#openstack-meeting-3; after that we will switch to an "office hours" format, 
where API-SIG members will be available in the #openstack-sdks channel. We will 
have at least two office hours scheduled per week, to allow for more 
participation across time zones. We will discuss that schedule at next week's 
meeting, so if you have any preferences on this, either attend that meeting, or 
reply to this email, so that we can make a schedule that works well for most 
people. We will also discontinue this weekly newsletter, and instead only send 
it when something of note needs to be shared with the wider community.

On a note, one of the biggest contributors to the SIG, Chris Dent (cdent), has 
finally realized that he is spread much too thinly these days, and needs to 
pull back from so many things demanding his time. So while he won't be as 
active in the group as before, I'm sure he'll be keeping an eye on the rest of 
us to make sure we don't mess things up too badly. So for all your good work, 
Chris, we say "Huzzah!".

If you're interested in helping out, here are some things to get you started:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

# Guidelines that are ready for wider review by the whole community.

* None

# Guidelines Currently Under Review [3]

* Add an api-design doc with design advice
  https://review.openstack.org/592003

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* Version and service discovery series
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://storyboard.openstack.org/#!/project/1039
[6] https://git.openstack.org/cgit/openstack/api-sig
[7] http://eavesdrop.openstack.org/#API_Special_Interest_Group

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] Nominating Tetsuro Nakamura for placement-core

2018-09-19 Thread Ed Leafe
On Sep 19, 2018, at 10:25 AM, Chris Dent  wrote:
> 
> I'd like to nominate Tetsuro Nakamura for membership in the
> placement-core team. 

I’m not a core, but if I were, I’d +1 that.


-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2018-09-06 Thread Ed Leafe
Greetings OpenStack community,

Once again we did not have anything too controversial to discuss this week. We 
talked a bit about the Open API 3.0 discussions, but until there is something 
concrete to work with, there really isn't much for the API-SIG to do other than 
facilitate these conversations. One SIG member, elmiko, shared his tool for 
code generation from Open API [9], which led to a broader discussion on code 
generation in general. Not exactly a pure API-related topic, but interesting 
nonetheless.

As there were no new guidelines to review or bugs to fix, the remaining part of 
the meeting was to discuss the plans for the API-SIG session [7] at the 
upcoming Denver PTG [8]. We were hoping to attract a bigger crowd by including 
a topic like "Running your serverless microversioned blockchain in Kubernetes", 
but unfortunately cdent liked that topic so much he sold it to some VCs and 
retired a rich man.

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

# Guidelines that are ready for wider review by the whole community.

* None

# Guidelines Currently Under Review [3]

* Add an api-design doc with design advice
  https://review.openstack.org/592003

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://storyboard.openstack.org/#!/project/1039
[6] https://git.openstack.org/cgit/openstack/api-sig
[7] https://etherpad.openstack.org/p/api-sig-stein-ptg
[8] https://www.openstack.org/ptg/
[9] https://gitlab.com/elmiko/deswag

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] [placement] Extraction: Phase 2

2018-09-06 Thread Ed Leafe
Now that the work to create a repo of Placement extracted from Nova that is 
passing tests has finished, there is still more work to be done. To help 
organize our efforts, we have created an etherpad [0] for this. At the bottom 
of that page is a section titled "TODOs for further cleaning up”. As we come 
across issues, they will be added to that section.

If you wish to help out by working on one of those issues, please mark that 
issue with your name so that we can avoid duplicating effort. And if you have 
any questions about the issue, please ask for help in the #openstack-placement 
IRC channel.

-- Ed Leafe

[0] https://etherpad.openstack.org/p/placement-extract-stein-3



__
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] better name for placement

2018-09-04 Thread Ed Leafe
On Sep 4, 2018, at 12:44 PM, Chris Dent  wrote:
> 
> Changing the name, again, is painful. Please, let's not do it.

I was in favor of coming up with a project name for placement. It was 
discussed, and the decision was made not to do so. We have since moved forward 
with the outcome of that decision. Revisiting it now would be painful, as Chris 
notes, and do nothing to advance the progress we have been making. Let’s focus 
on the work in front of us, and not waste time revisiting past decisions.

-- Ed Leafe






__
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] [api] Open API 3.0 for OpenStack API

2018-08-29 Thread Ed Leafe
On Aug 29, 2018, at 1:36 AM, Edison Xiang  wrote:
> 
> As we know, Open API 3.0 was released on July, 2017, it is about one year ago.
> Open API 3.0 support some new features like anyof, oneof and allof than Open 
> API 2.0(Swagger 2.0).
> Now OpenStack projects do not support Open API.
> Also I found some old emails in the Mail List about supporting Open API 2.0 
> in OpenStack.

There is currently an effort by some developers to investigate the possibility 
of using GraphQL with OpenStack APIs. What would Open API 3.0 provide that 
GraphQL would not? I’m asking because I don’t know enough about Open API to 
compare them.


-- Ed Leafe






__
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] [placement] extraction (technical) update

2018-08-28 Thread Ed Leafe
On Aug 28, 2018, at 10:47 AM, Matt Riedemann  wrote:
> 
>> 1.1 Run the git filter-branch on a copy of nova
>> 1.1.1 Add missing files to the file list:
>>   1.1.1.1 .gitignore
>>   1.1.1.2 # ANYTHING ELSE?
> 
> Unless I were to actually run the git filter-branch tooling to see what is 
> excluded from the new repo, I can't really say what is missing at this time. 
> I assume it would be clear during review - which is why I'm asking that we do 
> this stuff in gerrit where we do reviews.

Since I have run this tool a few times, I can answer that.

The tool removes all files and their history from git, saving only those you 
explicitly ask to keep. Every commit involving those files is kept, along with 
any other files that were part of that commit. The end result is a much smaller 
directory tree, and a much smaller .git directory (513M -> 113M).

Because the history is *removed*, running `git diff @^` on the result will not 
show the many files deleted by the history filter. So if you were looking for a 
diff in gerrit that shows all those deletions, it won’t be there. You can do a 
regular linux diff of the filtered directory and a nova directory to get a list 
of what has been removed, but that can be somewhat messy. I just want to set 
expectations when reviewing the extracted code in gerrit.


-- Ed Leafe






__
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] [placement] extraction (technical) update

2018-08-24 Thread Ed Leafe
On Aug 24, 2018, at 7:36 AM, Chris Dent  wrote:

> Over the past few days a few of us have been experimenting with
> extracting placement to its own repo, as has been discussed at
> length on this list, and in some etherpads:
> 
>https://etherpad.openstack.org/p/placement-extract-stein
>https://etherpad.openstack.org/p/placement-extraction-file-notes
> 
> As part of that, I've been doing some exploration to tease out the
> issues we're going to hit as we do it. None of this is work that
> will be merged, rather it is stuff to figure out what we need to
> know to do the eventual merging correctly and efficiently.

I’ve re-run the extraction, re-arranged the directories, and cleaned up most of 
the import pathing. The code is here: https://github.com/EdLeafe/placement.  I 
did a forced push to remove the first attempt.

-- Ed Leafe






__
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] UC Elections will not be held

2018-08-21 Thread Ed Leafe
As there were only 2 nominations for the 2 open seats, elections will not be 
needed. Congratulations to Matt Van Winkle and Joseph Sandoval!

-- Ed Leafe






__
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] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Ed Leafe
On Aug 20, 2018, at 6:27 PM, Matt Riedemann  wrote:
> 
> 3. The biggest fear is on the people involved in what placement on its own 
> might be, because the current placement team is made of, for the most part, 
> highly opinionated people that spend a lot of time arguing because they have, 
> at times, conflicting design principles which can impede getting anything 
> done. Concessions are made after (1) people weigh in from the "outside" or 
> (2) exhaustion sets in.

While this is certainly true, the experience with Nova is not unusual in that 
regard. There have always been highly opinionated people with conflicting 
ideas. Eventually a choice is made; occasionally it is by persuasion, but the 
exhaustion bit is there too. What we've seen in Nova over the years is that 
generally those who have different opinions eventually fall by the wayside, 
leaving behind those who share the opinion of the choice. It becomes 
self-selecting. There isn't any reason that a similar process will happen among 
those highly-opinionated placement people.

It was said in the #openstack-tc discussions, but for those on the mailing 
list, the biggest concern among the Nova core developers is that the consensus 
among Placement cores will certainly not align with the needs of Nova. I 
personally think that's ridiculous, and, as one of the very opinionated people 
involved, a bit insulting. No one wants to see either Nova or Placement to fail.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Ed Leafe
On Aug 20, 2018, at 5:31 PM, Matt Riedemann  wrote:
> 
>> I would like to hear from the Cinder and Neutron teams, especially those who 
>> were around when those compute sub-projects were split off into their own 
>> projects. Did you feel that being independent of compute helped or hindered 
>> you? And to those who are in those projects now, is there any sense that 
>> things would be better if you were still part of compute?
> 
> Neutron wasn't split out of nova.

Yes, that’s correct, and the continued existence of nova-network testifies to 
that. But what is also correct is that the networking effort was separated from 
Nova. Since the existing nova-network code wasn’t designed to handle the sort 
of networking that was envisioned to be needed, a separate Quantum project was 
started, by many of the people who contributed to nova-network in the past. 

That detail aside, the question is still valid: did the split from working 
within the Nova project to working as an independent project have positive or 
negative effects? Or both?

-- Ed Leafe






__
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] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Ed Leafe
On Aug 17, 2018, at 12:30 PM, Dan Smith  wrote:
> 
> Splitting it out to another repository within the compute umbrella (what
> do we call it these days?) satisfies the _technical_ concern of not
> being able to use placement without installing the rest of the nova code
> and dependency tree. Artificially creating more "perceived" distance
> sounds really political to me, so let's be sure we're upfront about the
> reasoning for doing that if so :)

Characterizing the proposed separation as “artificial” seems to be quite 
political in itself.

Of course there are political factors; it would be naive to think otherwise. 
That’s why I’d like to get input from those people who are not in the middle of 
it, and have no political motivation. I’d like this to be a technical 
discussion, with as little political overtones as possible.

-- Ed Leafe






__
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] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Ed Leafe
On Aug 17, 2018, at 10:51 AM, Chris Dent  wrote:
> 
> One of the questions that has come up on the etherpad is about how
> placement should be positioned, as a project, after the extraction.
> The options are:
> 
> * A repo within the compute project
> * Its own project, either:
>  * working towards being official and governed
>  * official and governed from the start

I would like to hear from the Cinder and Neutron teams, especially those who 
were around when those compute sub-projects were split off into their own 
projects. Did you feel that being independent of compute helped or hindered 
you? And to those who are in those projects now, is there any sense that things 
would be better if you were still part of compute?

My opinion has been that Placement should have been separate from the start. 
The longer we keep Placement inside of Nova, the more painful it will be to 
extract, and hence the likelihood of that every happening is greatly diminished.


-- Ed Leafe






__
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] User Committee Nominations Closing Soon!

2018-08-16 Thread Ed Leafe
As I write this, there are just over 12 hours left to get in your nominations 
for the OpenStack User Committee. Nominations close at August 17, 05:59 UTC.

If you are an AUC and thinking about running what's stopping you? If you know 
of someone who would make a great committee member nominate them (with their 
permission, of course)! Help make a difference for Operators, Users and the 
Community!

-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2018-08-16 Thread Ed Leafe
Greetings OpenStack community,

Another cozy meeting today, as conferences and summer holidays reduced our 
attendees. We mainly focused on  the agenda [7] for the upcoming Denver PTG 
[8]. One item we added was consideration of a spec for common healthcheck 
middleware across projects [9]. This had been proposed back in January, and 
seemed to have a lot of initial interest, but there hasn't been any activity on 
it since March. There does seem to be some interest in it still, but no one 
with enough free cycles to keep it updated. So we invite anyone who has an 
interest in this to come to the API-SIG session at the PTG on Monday, or, if 
you can't make it, add your comments to the review.

Two of the patches [10][11] introduced by cdent last week were deemed to not be 
changes to the guidelines, but rather minor additions, so given that they were 
approved by the cores, they were merged. The remaining patch [12] involves a 
lot more thought and discussion; it could be the subject of a book all by 
itself! But we'd like to keep it short and to the point. We also don't have 
time to write a book!

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

# Guidelines that are ready for wider review by the whole community.

* None

# Guidelines Currently Under Review [3]

* Add an api-design doc with design advice
  https://review.openstack.org/592003

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://etherpad.openstack.org/p/api-sig-stein-ptg
[8] https://www.openstack.org/ptg/
[9] https://review.openstack.org/#/c/531456/
[10] https://review.openstack.org/589131
[11] https://review.openstack.org/589132
[12] https://review.openstack.org/592003

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] UC nomination period is now open!

2018-08-06 Thread Ed Leafe
As the subject says, the nomination period for the summer[0] User Committee 
elections is now open. 

Any individual member of the Foundation who is an Active User Contributor (AUC) 
can propose their candidacy (except the three sitting UC members elected in the 
previous election).

Self-nomination is common; no third party nomination is required. Nominations 
are made by sending an email to the user-commit...@lists.openstack.org 
mailing-list, with the subject: “UC candidacy” by August 17, 05:59 UTC. The 
email can include a description of the candidate platform. The candidacy is 
then confirmed by one of the election officials, after verification of the 
electorate status of the candidate.

[0] Sorry, southern hemisphere people!


-- Ed Leafe






__
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] Subject: [all][api] POST /api-sig/news

2018-07-26 Thread Ed Leafe
Greetings OpenStack community,

We had a short but sweet meeting today, as all four core members were around 
for the first time in several weeks. The one action item from last week, 
reaching out to the people working on the GraphQL experiment, was done, but so 
far we have not heard back on their progress.

notmyname suggested that we investigate the IETF [7] draft proposal for Best 
Practices when building HTTP protocols [8] which may be relevant to our work, 
so we all agreed to review the document (all 30 pages of it!) by next week, 
where we will discuss it further.

Finally, we merged two patches that had had universal approval (yes, the 
*entire* universe), sending cdent's stats through the roof.

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

* Expand schema for error.codes to reflect reality
  https://review.openstack.org/#/c/580703/

* Add links to error-example.json
  https://review.openstack.org/#/c/578369/

# API Guidelines Proposed for Freeze

* None

# Guidelines that are ready for wider review by the whole community.

* None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://ietf.org/
[8] https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-06

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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][api][grapql] Proof of Concept

2018-07-25 Thread Ed Leafe
On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil  wrote:
> 
> The branch is now available under feature/graphql on the neutron core 
> repository [1].

I wanted to follow up with you on this effort. I haven’t seen any activity on 
StoryBoard for several weeks now, and wanted to be sure that there was nothing 
blocking you that we could help with.


-- Ed Leafe






__
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][api[[graphql] A starting point

2018-06-22 Thread Ed Leafe
On Jun 15, 2018, at 5:42 PM, Gilles Dubreuil  wrote:
> 
> This initial patch [1]  allows to retrieve networks, subnets.
> 
> This is very easy, thanks to the graphene-sqlalchemy helper.
> 
> The edges, nodes layer might be confusing at first meanwhile they make the 
> Schema Relay-compliant in order to offer re-fetching, pagination features out 
> of the box.
> 
> The next priority is to set the unit test in order to implement mutations.
> 
> Could someone help provide a base in order to respect Neutron test 
> requirements?

Glad to see some progress! 

We have migrated the API-SIG from Launchpad to StoryBoard [0], specifically so 
that your group has a place to record stories, tasks, etc. Please feel free to 
use this to help coordinated your work.

[0] https://storyboard.openstack.org/#!/project/1039


-- Ed Leafe






__
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] TC Report 18-25

2018-06-19 Thread Ed Leafe
On Jun 19, 2018, at 12:48 PM, Chris Dent  wrote:
> 
> Many of the things that get written will start off wrong but the
> only way they have a chance of becoming right is if they are written
> in the first place.

This.

Too many people are afraid of doing anything that might turn out to be the 
"wrong" thing that nothing gets done.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [all][api] POST /api-sig/news

2018-06-14 Thread Ed Leafe
Greetings OpenStack community,

A small, intimate meeting today, as only cdent and edleafe were present. We 
discussed the work being done [7] to migrate our bug/issue tracking from 
Launchpad to StoryBoard [8]. The change to the infra docs will trigger the 
setup of StoryBoard when it merges. Once StoryBoard is up and running for the 
API-SIG, we will notify the GraphQL team, so that they can track their stories 
and tasks there.

There was also more progress on updating the name of this group. When we 
switched from the API-WG to the API-SIG a few months ago, there were several 
places where we could make the change without much fuss. But some other places, 
such as Gerrit, required intervention from the infra team. We thought it would 
be too much bother, so we didn't spend time on it. But it turns out that it's 
not that difficult for infra to do during Gerrit downtimes, so that change [9] 
was also submitted.

There being no recent changes to pending guidelines nor to bugs, we ended the 
meeting early.

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://review.openstack.org/575120
[8] https://storyboard.openstack.org/#!/page/about
[9] https://review.openstack.org/575478

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] Organizational diversity tag

2018-06-04 Thread Ed Leafe
On Jun 4, 2018, at 2:10 PM, Doug Hellmann  wrote:
> 
>> Those rules were added because we wanted to avoid the appearance of one 
>> company implementing features that would only be beneficial to it. This 
>> arose from concerns in the early days when Rackspace was the dominant 
>> contributor: many of the other companies involved in OpenStack were worried 
>> that they would be investing their workers in a project that would only 
>> benefit Rackspace. As far as I know, there were never specific cases where 
>> Rackspace or any other company tried to push features in that no one else 
>> supported..
>> 
>> So even if now it doesn't seem that there is a problem, and we could remove 
>> these restrictions without ill effect, it just seems prudent to keep them. 
>> If a project is so small that the majority of its contributors/cores are 
>> from one company, maybe it should be an internal project for that company, 
>> and not a community project.
>> 
>> -- Ed Leafe
> 
> Where was the rule added, though? I am aware of some individual teams
> with the rule, but AFAIK it was never a global rule. It's certainly not
> in any of the projects for which I am currently a core reviewer.

If you're looking for a reference to a particular bit of governance, I can't 
help you there. But being one of the Nova cores who worked for Rackspace back 
then, I was part of many such discussions, and can tell you that Rackspace was 
very conscious of not wanting to appear to be dictating the direction, and that 
this agreement not to approve code committed by other Rackers was an important 
part of that.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] Organizational diversity tag

2018-06-04 Thread Ed Leafe
On Jun 4, 2018, at 7:05 AM, Jay S Bryant  wrote:

>> Do we have that problem? I honestly don't know how much pressure other
>> folks are feeling. My impression is that we've mostly become good at
>> finding the necessary compromises, but my experience doesn't cover all
>> of our teams.
> In my experience this hasn't been a problem for quite some time.  In the 
> past, at least for Cinder, there were some minor cases of this but as 
> projects have matured this has been less of an issue.

Those rules were added because we wanted to avoid the appearance of one company 
implementing features that would only be beneficial to it. This arose from 
concerns in the early days when Rackspace was the dominant contributor: many of 
the other companies involved in OpenStack were worried that they would be 
investing their workers in a project that would only benefit Rackspace. As far 
as I know, there were never specific cases where Rackspace or any other company 
tried to push features in that no one else supported..

So even if now it doesn't seem that there is a problem, and we could remove 
these restrictions without ill effect, it just seems prudent to keep them. If a 
project is so small that the majority of its contributors/cores are from one 
company, maybe it should be an internal project for that company, and not a 
community project.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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][api][grapql] Proof of Concept

2018-05-30 Thread Ed Leafe
On May 6, 2018, at 8:01 AM, Gilles Dubreuil  wrote:

> Regarding the choice of Neutron as PoC, I'm sorry for not providing much 
> details when I said "because of its specific data model",
> effectively the original mention was  "its API exposes things at an 
> individual table level, requiring the client to join that information to get 
> the answers they need".
> I realize now such description probably applies to many OpenStack APIs.
> So I'm not sure what was the reason for choosing Neutron.

Blame Monty!

It was Monty who suggested Neutron due to his particular experience working 
with the API. Since none of the rest of us in the API-SIG had any better 
suggestions, that was what we passed on to you. But I think that any target 
that demonstrates the advantages to be had by adopting GraphQL is fine. So if 
the team working on this think they can create a more impressive PoC with 
another API, the API-SIG will support that.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] A culture change (nitpicking)

2018-05-30 Thread Ed Leafe
On May 30, 2018, at 5:11 AM, Dmitry Tantsur  wrote:

> Whatever decision the TC takes, I would like it to make sure that we don't 
> paint putting -1 as a bad act. Nor do I want "if you care, just follow-up" to 
> be an excuse for putting up bad contributions.
> 
> Additionally, I would like to have something saying that a -1 is valid and 
> appropriate, if a contribution substantially increases the project's 
> technical debt. After already spending *days* refactoring ironic unit tests, 
> I will -1 the hell out of a patch that will try to bring them back to their 
> initial state, I promise :)

Yes to this. -1 should never mean anything other than "some more work needs to 
be done before this can merge". It most certainly does not mean "your code is 
bad and you should feel terrible".

While this started as a discussion about reducing nitpicking, which I think we 
can all embrace, we shouldn't let it slide into imagining that contributors are 
such fragile things that pointing out an error/problem in the code is seen as a 
personal attack. Of course you should not be mean when you do so. But that's 
very, very rare in my OpenStack experience. Nitpicking, on the other hand, is 
much more prevalent, and I welcome these efforts to reduce it.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] nova-manage cell_v2 map_instances uses invalid UUID as marker in the db

2018-05-10 Thread Ed Leafe
On May 10, 2018, at 12:50 AM, Takashi Natsume <natsume.taka...@lab.ntt.co.jp> 
wrote:
> 
> So it is one way to change the command to stop storing a 'marker' value
> in the InstanceMapping (instance_mappings) DB table
> and return (print) a 'marker' value and be able to be specifid
> the 'marker' value as the command line argument.

Anything that gets rid of the awful hack used for the instance mapping code 
would be welcome. Storing a marker in the table is terrible, and then munging a 
UUID to be a not-UUID is even worse. My cleanup at least got rid of the second 
hack, but I would have preferred to fix the whole thing by not storing the 
marker in the first place.

-- Ed Leafe






__
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] [api] REST limitations and GraghQL inception?

2018-05-03 Thread Ed Leafe
On May 3, 2018, at 12:50 PM, Jay Pipes <jaypi...@gmail.com> wrote:
> 
> Bottom line for me would be what is the perceivable benefit that all of our 
> users would receive given the (very costly) overhaul of our APIs that would 
> likely be required.

That was our thinking: no one would agree to such an effort without first 
demonstrating some tangible results. Hence the idea for an experiment with just 
a single service, done by those interested in seeing it happen. If GraphQL can 
do what they imagine it could do, then they would be able to demonstrate the 
benefit that you (and everyone else) would want to see.


-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2018-05-03 Thread Ed Leafe
Greetings OpenStack community,

A well-attended meeting today. I'm pleased to report that a good time was had 
by all.

The discussion centered primarily on the email to the dev list [7] from Gilles 
Dubreuil regarding the possibility of using GraphQL [8] as a 
wrapper/replacement for the OpenStack APIs/SDKs. None of us are familiar with 
GraphQL in more than a cursory way, so we thought it would be best to propose 
starting with a limited proof-of-concept test. This would involve a team of 
people interested in GraphQL to work separately to wrap a single OpenStack 
service, and then, based on the results, either make it something we embrace 
OpenStack-wide, or chalk up as another interesting experiment. mordred 
suggested that they use Neutron as the test case, as their API requires a lot 
of client-side work for many typical queries. edleafe agreed to respond on the 
mailing list with these thoughts. We also agreed that edleafe needs to be more 
mindful of his phrasing in emails.

Due to the late interest of Gilles and others, we decided to resurrect our BoF 
session at the upcoming Vancouver Forum. If you will be there, and you have an 
interest in anything API- or SDK-related, please plan on joining us!

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None

# Guidelines Currently Under Review [3]

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129987.html
[8] http://graphql.org/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] [api] REST limitations and GraghQL inception?

2018-05-03 Thread Ed Leafe
On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com> wrote:
> 
>> • We should get a common consensus before all projects start to implement it.
> 
> This is going to be raised during the API SIG weekly meeting later this week.
> API developers (at least one) from every project are strongly welcomed to 
> participate.
> I suppose it makes sense for the API SIG to be the place to discuss it, at 
> least initially. 

It was indeed discussed, and we think that it would be a worthwhile experiment. 
But it would be a difficult, if not impossible, proposal to have adopted 
OpenStack-wide without some data to back it up. So what we thought would be a 
good starting point would be to have a group of individuals interested in 
GraphQL form an informal team and proceed to wrap one OpenStack API as a 
proof-of-concept. Monty Taylor suggested Neutron as an excellent candidate, as 
its API exposes things at an individual table level, requiring the client to 
join that information to get the answers they need.

Once that is done, we could examine the results, and use them as the basis for 
proceeding with something more comprehensive. Does that sound like a good 
approach to (all of) you?

-- Ed Leafe






__
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-operators] [nova] Default scheduler filters survey

2018-04-29 Thread Ed Leafe
On Apr 29, 2018, at 1:34 PM, Artom Lifshitz <alifs...@redhat.com> wrote:
> 
> Based on that, we can definitely say that SameHostFilter and
> DifferentHostFilter do *not* belong in the defaults. In fact, we got
> our defaults pretty spot on, based on this admittedly very limited
> dataset. The only frequently occurring filter that's not in our
> defaults is AggregateInstanceExtraSpecsFilter.

Another data point that might be illuminating is: how many sites use a custom 
(i.e., not in-tree) filter or weigher? One of the original design tenets of the 
scheduler was that we did not want to artificially limit what people could use 
to control their deployments, but inside of Nova there is a lot of confusion as 
to whether anyone is using anything but the included filters.

So - does anyone out there rely on a filter and/or weigher that they wrote 
themselves, and maintain outside of OpenStack?

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [placement][nova] Decision time on granular request groups for like resources

2018-04-18 Thread Ed Leafe
On Apr 18, 2018, at 10:58 AM, Matt Riedemann <mriede...@gmail.com> wrote:
> 
> So for this case, if I'm requesting numbered request groups, why doesn't the 
> API just require that I pass a query parameter telling it how I'd like those 
> requests to be handled, either via affinity or anti-affinity.

That makes a lot of sense. Since we are already suffixing the query param 
“resources” to indicate granular, why not add a clarifying term to that suffix? 
E.g., “resources1=“ -> “resources1d” (for ‘different’). The exact string we use 
can be bike shedded, but requiring it be specified sounds pretty sane to me.

-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2018-04-12 Thread Ed Leafe
Greetings OpenStack community,

It was a fairly quick meeting today, as we weren't able to find anything to 
argue about. That doesn't happen too often. :)

We agreed that the revamped HTTP guidelines [8] should be merged, as they were 
strictly formatting changes, and no content change. We also merged the change 
to update the errors guidance [9] to use service-type instead of service-name, 
as that had been frozen last week, with no negative feedback since then.

We still have not gotten a lot of feedback from the SDK community about topics 
to discuss at the upcoming Vancouver Forum. If you are involved with SDK 
development and have something you'd like to discuss there, please reply to the 
openstack-dev mailing list thread [7] with your thoughts.

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

* Update the errors guidance to use service-type for code
  https://review.openstack.org/#/c/554921/

* Break up the HTTP guideline into smaller documents
  https://review.openstack.org/#/c/554234/

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None

# Guidelines Currently Under Review [3]

* Add guidance on needing cache-control headers
  https://review.openstack.org/550468

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000353.html
[8] https://review.openstack.org/#/c/554234/
[9] https://review.openstack.org/#/c/554921/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] [cyborg] Race condition in the Cyborg/Nova flow

2018-03-29 Thread Ed Leafe
On Mar 29, 2018, at 12:57 PM, Eric Fried <openst...@fried.cc> wrote:
> 
>> That means that for the (re)-programming scenarios you need to
>> dynamically adjust the inventory of a particular FPGA resource provider.
> 
> Oh, see, this is something I had *thought* was a non-starter. 

I need to work on my communication skills. This is what I’ve been saying all 
along.

-- Ed Leafe






__
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] EC2 cleanup ?

2018-03-23 Thread Ed Leafe
On Mar 23, 2018, at 10:16 AM, Matt Riedemann <mriede...@gmail.com> wrote:
> 
>> seems we have a EC2 implementation in api layer and deprecated since Mitaka, 
>> maybe eligible to be removed this cycle?
> 
> That is easier said than done. There have been a couple of related attempts 
> in the past:
> 
> https://review.openstack.org/#/c/266425/
> 
> https://review.openstack.org/#/c/282872/
> 
> I don't remember exactly where those fell down, but it's worth looking at 
> this first before trying to do this again.

If we do, let’s also remove the unnecessary extra directory level in 
nova/api/openstack. There is only one Nova API, so the extra ‘openstack’ level 
is no longer needed.

-- Ed Leafe






__
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] [Cyborg] why cyborg can not support an accelerators info list for more than one host?

2018-03-21 Thread Ed Leafe
On Mar 21, 2018, at 11:35 AM, 少合冯 <lvmxhs...@gmail.com> wrote:
> 
>> By default, hosts are weighed one by one. You can subclass the BaseWeigher 
>> (in nova/weights.py) to weigh all objects at once.
> 
> Does that means it require call cyborg accelerator one by one?  the pseudo 
> code as follow:
> for host in hosts:
>accelerator = cyborg.http_get_ accelerator(host)
>do_weight_by_accelerator
>
> Instead of call cyborg accelerators once,  the pseudo code as follow :
> accelerators = cyborg.http_get_ accelerator(hosts)
> for acc in accelerators:
>do_weight_by_accelerator

What it means is that if you override the weigh_objects() method of the 
BaseWeigher class, you can make a single call to Cyborg with a list of all the 
hosts. That call could then create a list of weights for all the hosts and 
return that. So if you have 100 hosts, you don’t need to make 100 calls to 
Cyborg; only 1.

-- Ed Leafe






__
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] [Cyborg] why cyborg can not support an accelerators info list for more than one host?

2018-03-21 Thread Ed Leafe
On Mar 21, 2018, at 10:56 AM, 少合冯 <lvmxhs...@gmail.com> wrote:
> 
> Sorry, I did not attend the PTG. 
> Is it said there is a conclusion:
> Scheduler weigher will call into Cyborg REST API for each host instead of one 
> REST API for all hosts.  
> Is there some reason?

By default, hosts are weighed one by one. You can subclass the BaseWeigher (in 
nova/weights.py) to weigh all objects at once.

-- Ed Leafe






__
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] [api] APAC-friendly API-SIG meeting times

2018-03-16 Thread Ed Leafe
On Mar 15, 2018, at 10:31 PM, Gilles Dubreuil <gdubr...@redhat.com> wrote:
> 
> Any chance we can progress on this one?
> 
> I believe there are not enough participants to split the API SIG meeting in 
> 2, and also more likely because of the same lack of people across the 2 it 
> could make it pretty inefficient. Therefore I think changing the main meeting 
> time to another might be better but I could be wrong.
> 
> Anyway in all cases I can't make progress with a meeting in the middle of the 
> night for me so I would appreciate if we could re-activate this discussion.

What range of times would work for you? 

-- Ed Leafe






__
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] Fwd: 2.7 EOL = 2020 January 1

2018-03-14 Thread Ed Leafe
Just FYI to all the people who don't prioritize moving our code to Python3:

> Begin forwarded message:
> 
> From: Terry Reedy <tjre...@udel.edu>
> Subject: 2.7 EOL = 2020 January 1
> Date: March 13, 2018 at 9:58:42 AM CDT
> To: python-l...@python.org
> 
> On March 10, on thread "Python 2.7 -- bugfix or security before EOL?", Guido 
> van Russum wrote
> 
> "The way I see the situation for 2.7 is that EOL is January 1st, 2020, and 
> there will be no updates, not even source-only security patches, after that 
> date. Support (from the core devs, the PSF, and python.org) stops completely 
> on that date. If you want support for 2.7 beyond that day you will have to 
> pay a commercial vendor. Of course it's open source so people are also 
> welcome to fork it. But the core devs have toiled long enough, and the 2020 
> EOL date (an extension from the originally annouced 2015 EOL!) was announced 
> with sufficient lead time and fanfare that I don't feel bad about stopping to 
> support it at all."
> 
> Two days later, Benjamin Peterson, the 2.7 release manager, replied "Sounds 
> good to me. I've updated the PEP to say 2.7 is completely dead on Jan 1 
> 2020." adding "The final release may not literally be on January 1st".
> 
> https://www.python.org/dev/peps/pep-0373/ now says
> "2.7 will receive bugfix support until January 1, 2020."
> 
> -- 
> Terry Jan Reedy
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 


-- Ed Leafe





__
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] [cyborg]No Meeting This Week

2018-03-08 Thread Ed Leafe
On Mar 5, 2018, at 9:51 PM, Zhipeng Huang <zhipengh...@gmail.com> wrote:

> As most of us are rekubrating from PTG and snowenpstack last week, let's 
> cancel the team meeting this week. At the mean time I have solicitate the 
> meeting summary from topic leads, and will send out a summary of the 
> summaries later :)

When is your meeting? I don’t see it listed on http://eavesdrop.openstack.org.


-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2018-03-08 Thread Ed Leafe
Greetings OpenStack community,

Well, after a wonderful week in Dublin, it's back to work for the API-SIG. We 
had a productive session at the PTG, and came away from it with several action 
items for each of us. Due to travel and digging out from a week away, none of 
us had started them. Oh, except for cdent, who had already started on his 
(showoff!). It was also noted that we received an excellent compliment [7] from 
notmyname for the sessions at the PTG. We do try to be inclusive and hear all 
voices, so that was very important to us.

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week.

# Guidelines Currently Under Review [3]

* Add guidance on needing cache-control headers
  https://review.openstack.org/550468

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://twitter.com/anticdent/status/968503362927972353

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2018-02-22 Thread Ed Leafe
Greetings OpenStack community,

Well, with PTG just around the corner, and the API-SIG portion of that just 4 
days away, we elected to have a quick meeting today. The only topic we needed 
to discuss was the results of our votes for the topics to cover on Monday. We 
used an etherpad with the proposed topics [7], and edleafe compiled the results 
here [8]. Since "microversions" appears in one of the topics, I'm sure we'll be 
in discussions all day.

So if you will be in Dublin next week, the API-SIG is meeting all day Mondy. 
Please join us!

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week.

# Guidelines Currently Under Review [3]

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] https://etherpad.openstack.org/p/api-sig-ptg-rocky
[8] https://ethercalc.openstack.org/xja22ghws13i

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] [Election] PTL Election Results & Conclusion

2018-02-15 Thread Ed Leafe
On Feb 15, 2018, at 9:43 AM, Steven Dake (stdake) <std...@cisco.com> wrote:
> 
> The election process I'm certain is very difficult to execute, and as a 
> community member, I'd like to thank the election officials for their work.

Having done it once, I can agree! Thanks for making things run so smoothly.


-- Ed Leafe






__
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] [kolla] role change and introductions

2018-02-15 Thread Ed Leafe
On Feb 15, 2018, at 2:41 PM, Marcin Juszkiewicz <marcin.juszkiew...@linaro.org> 
wrote:
> 
>> Second, there will be 2 others from my ppc64le team getting involved
>> in Kolla, Mark Hamzy and Ed Leafe. Ed will be attending PTG and will
>> try to get a chance to meet a few of you there.
> 
> Please tell him that I would like to chat about ppc64le stuff ;D

Of course, as long as you don’t expect me to know very much! :)

-- Ed Leafe






__
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][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

2018-02-12 Thread Ed Leafe
On Feb 12, 2018, at 9:57 AM, Chris Dent <cdent...@anticdent.org> wrote:
> 
> Tuesday would be best for me as Monday is api-sig day.

Same, for the same reason.


-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2018-02-08 Thread Ed Leafe
Greetings OpenStack community,

Today's meeting was chock-full of interesting discussion. Let me recap it for 
you.

We began with a follow-up conversation about the use of "action" URLs (as 
opposed to resource-based URLs). The origin of this discussion came from an 
email posted to the dev list by Tommy Hu [7], describing how several types of 
actions are currently being handled through the cinder and nova REST 
interfaces. After last week's API-SIG discussion, edleafe replied [8], which 
was followed by some more email discussion. It seems that there is still a lot 
of impetus to simply "get things working" instead of "let's do it in a 
consistent manner across OpenStack". If you have an opinion on this issue, 
please reply on the mailing list!

On the topic of the PTG, the SIG has created an etherpad [9] where agenda items 
are starting to be proposed. If you have any topic that you would like to 
discuss, or see discussed, please add it to that etherpad. We also decided that 
we are not cute enough to merit taking a group photo at the PTG.

We discussed the spec by Gilles Dubreuil [10] for creating a guideline for 
API-Schema to make APIs more machine-discoverable. We felt that this was more 
of a one-off need rather than something we'd like to see rolled out across all 
OpenStack APIs. Furthermore, API-Schema will be problematic for services that 
use microversions. If you have some insight or opinions on this, please add 
your comments to that review.

cdent then won the award for the Quote of the Day [11].

Finally, we discussed a bug [12] that is the result of the Nova API not 
properly including caching information in the headers of its replies. There is 
some pushback from the Nova team as to whether this is a bug or a request for a 
new feature. We unanimously agreed that it is indeed a bug, and should be 
remedied as soon as possible. Again, please add your perspective to that bug 
report.

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week.

# Guidelines Currently Under Review [3]

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack-dev/2018-January/126334.html
[8] http://lists.openstack.org/pipermail/openstack-dev/2018-February/126891.html
[9] https://etherpad.openstack.org/p/api-sig-ptg-rocky
[10] https://review.openstack.org/#/c/524467/
[11] 
http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-02-08-16.00.log.html#l-131
[12] https://bugs.launchpad.net/nova/+bug/1747935

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

2018-02-07 Thread Ed Leafe
On Feb 2, 2018, at 2:11 AM, Duncan Thomas <duncan.tho...@gmail.com> wrote:
> 
> So I guess my question here is why is being RESTful good? Sure it's (very, 
> very loosely) a standard, but what are the actual advantages? Standards come 
> and go, what we want most of all is a good quality, easy to use API.

REST is HTTP. I don’t think that that is a “loose” standard by any measure.

> I'm not saying that going RESTful is wrong, but I don't see much discussion 
> about what the advantages are, only about how close we are to implementing it.

Here’s a quick summary of the advantages, courtesy of SO:

https://stackoverflow.com/questions/5320003/why-we-should-use-rest

REST is the standard for OpenStack APIs. Our job in the API-SIG is to help all 
projects develop their APIs to be as consistent as possible without using a 
top-down, heavy-handed approach. That’s why we included a suggestion for how to 
make your RPC-ish API consistent with other projects that also use an RPC-like 
approach to parts of their API.


-- Ed Leafe






__
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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

2018-02-01 Thread Ed Leafe
On Jan 18, 2018, at 4:07 AM, TommyLike Hu <tommylik...@gmail.com> wrote:

>Recently We found an issue related to our OpenStack action APIs. We 
> usually expose our OpenStack APIs by registering them to our API Gateway (for 
> instance Kong [1]), but it becomes very difficult when regarding to action 
> APIs. We can not register and control them seperately because them all share 
> the same request url which will be used as the identity in the gateway 
> service, not say rate limiting and other advanced gateway features, take a 
> look at the basic resources in OpenStack

We discussed your email at today’s API-SIG meeting [0]. This is an area that is 
always contentious in the RESTful world. Actions, tasks, and state changes are 
not actual resources, and in a pure REST design they should never be part of 
the URL. Instead, you should POST to the actual resource, with the desired 
action in the body. So in your example:

> URL:/volumes/{volume_id}/action
> BODY:{'extend':{}}

the preferred way of achieving this is:

URL: POST /volumes/{volume_id}
BODY: {‘action’: ‘extend’, ‘params’: {}}

The handler for the POST action should inspect the body, and call the 
appropriate method.

Having said that, we realize that a lot of OpenStack services have adopted the 
more RPC-like approach that you’ve outlined. So while we strongly recommend a 
standard RESTful approach, if you have already released an RPC-like API, our 
advice is:

a) avoid having every possible verb in the URL. In other words, don’t use:
  /volumes/{volume_id}/mount
  /volumes/{volume_id}/umount
  /volumes/{volume_id}/extend
This moves you further into RPC-land, and will make updating your API to a more 
RESTful design more difficult.

b) choose a standard term for the item in the URL. In other words, always use 
‘action’ or ‘task’ or whatever else you have adopted. Don’t mix terminology. 
Then pass the action to perform, along with any parameters in the body. This 
will make it easier to transition to a RESTful design by later updating the 
handlers to first inspect the BODY instead of relying upon the URL to determine 
what action to perform.

You might also want to contact the Kong developers to see if there is a way to 
work with a RESTful API design.

-- Ed Leafe

[0] 
http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-02-01-16.02.log.html#l-28




__
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] PTL Election Season

2018-01-22 Thread Ed Leafe
On Jan 22, 2018, at 5:09 PM, Matt Riedemann <mriede...@gmail.com> wrote:

> To anyone that cares, I don't plan on running for Nova PTL again for the 
> Rocky release. Queens was my fourth tour and it's definitely time for someone 
> else to get the opportunity to lead here. I don't plan on going anywhere and 
> I'll be here to help with any transition needed assuming someone else (or a 
> couple of people hopefully) will run in the election. It's been a great 
> experience and I thank everyone that has had to put up with me and my 
> obsessive paperwork and process disorder in the meantime.

I still don't understand how anyone could do what you have done over these past 
two years and not a) had a stress-induced heart attack or b) gotten divorced.

Thanks for the hard work!

-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2018-01-18 Thread Ed Leafe
Greetings OpenStack community,

A very quiet meeting today [7], which you would expect with the absence of 
cdent and elmiko. The main discussion was about the guideline on exposing 
microversions in SDKs [8] by dtantsur. The focus of the discussion was about 
how to handle the distinction between what he calls a "low-level SDK" (such as 
novaclient, ironicclient, etc.), and a "high-level SDK" (such as Shade, 
jclouds, or OpenStack.NET). We agreed to continue the discussion next week when 
we can have additional points of view available to come up with more clarity.

Oh, and we merged the improvement to the guideline on pagination. Thanks, 
mordred!

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

* Expand note about rfc5988 link header
  https://review.openstack.org/#/c/531914/

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week.

# Guidelines Currently Under Review [3]

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

* WIP: Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] 
http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-01-18-16.00.log.html
[8] https://review.openstack.org/#/c/532814/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

2018-01-16 Thread Ed Leafe
On Jan 16, 2018, at 7:21 PM, Zhenyu Zheng <zhengzhenyul...@gmail.com> wrote:

> Thanks for the info, so it seems we are not going to implement aggregate 
> overcommit ratio in placement at least in the near future?

I would go so far as to say that we are not going to implement aggregate 
overcommit ratio in placement at all. Placement has the concept of a Resource 
Provider as its base unit, and aggregates really don't fit in this model at all.

If you need that sort of grouping, perhaps a tool that would assign a single 
ratio to all the members of an aggregate would be a good way to convert to the 
new paradigm.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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 Ed Leafe
On Dec 14, 2017, at 7:07 AM, Thierry Carrez <thie...@openstack.org> wrote:
> 
> It takes time to get a feature merged (or any significant work done) in
> OpenStack. It takes time to get reviews, we need to be careful about not
> breaking all our users, etc. If you are a 20% time person, it's just
> impossible to get something significant done within the timeframe of a
> cycle, which leads to frustration as you have to get your stuff
> re-discussed and re-prioritized at the start of the next cycle.

In my experience, the longer a patch (or worse, patch series) sits around, the 
staler it gets. Others are merging changes, so the long-lived patch series has 
to be constantly rebased. The 20% developer would be spending a greater 
proportion of her time figuring out how to solve the rebase conflicts instead 
of just focusing on her code.

I’m not saying that the advantages you mention aren’t real. I’m just pointing 
out that there are downsides to stretching things out.

-- Ed Leafe






__
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 Ed Leafe
On Dec 14, 2017, at 3:01 AM, Thomas Goirand <z...@debian.org> wrote:
> 
> As a package maintainer who no longer can follow the high pace, I very
> much support this change.

So you’re saying that you would be ignoring any intermediate releases?

-- Ed Leafe






__
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 Ed Leafe
On Dec 14, 2017, at 12:55 AM, Clint Byrum <cl...@fewbar.com> wrote:

>> The rest of OpenStack is what Nova originally was. It was split into many 
>> different project because of the sheer complexity of the tasks it had to 
>> perform. But splitting it up required that we occasionally have to make sure 
>> that we're all still working together well.
> 
> My entire point is that we should draw clearer lines around our API's and
> admit that we have a ton of tight coupling that requires us to release
> things in an integrated fashion.
> 
> While I agree, where we're at is a tightly coupled mess, what I don't agree
> with is that the answer is to keep shipping the mess.

I agree 100% with that sentiment. However, *until* we achieve something close 
to that, we have to continue to ship “this mess”. Taking a mess and shipping it 
separately doesn’t clean up the mess.


-- Ed Leafe






__
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-13 Thread Ed Leafe
On Dec 13, 2017, at 5:44 PM, Clint Byrum <cl...@fewbar.com> wrote:

> One thing I've always admired about Swift was how immune to the cadence Swift
> appears to be.

As I've pointed out before [0], Swift is a whole 'nother thing.

It does not have API interdependencies with anything else in OpenStack. It is 
free to do things its own way on its own schedule.

The rest of OpenStack is what Nova originally was. It was split into many 
different project because of the sheer complexity of the tasks it had to 
perform. But splitting it up required that we occasionally have to make sure 
that we're all still working together well.

[0] https://blog.leafe.com/on_swift/


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-13 Thread Ed Leafe
On Dec 13, 2017, at 4:38 PM, German Eichberger 
<german.eichber...@rackspace.com> wrote:

> It looks like the implicit expectation is that devs also need to attend the 
> Forums at the summit in addition to the PTG. The Forums, though important, 
> hardly made it worthwhile for me to attend the summit (and in fact I skipped 
> Sydney). On the other hand some devs got together and hashed out some plans 
> for their projects. Personally, I feel the PTG is not working if we also have 
> summits – and having two summits and one PTG will make things worse. 
> Therefore I propose to scrap the PTG and add “design summits” back to the 
> OpenStack summit. As a side effect this will be a better on-ramp for casual 
> developers who can’t justify going to the PTG and ensure enough developers 
> are on-hand to hear the operator’s feedback.

The original purpose of the summits were for the developers to get together to 
plan what they would work on for the next few months. Over time, the big money 
came pouring in, and they became huge marketing events, with developers pushed 
off to the fringes. The recent PTGs have been refreshing because they are more 
like the original events, where there is no distraction by the corporate 
marketing machines, and we can focus on getting shit done.

My question is: if we only have a release once a year, why do we need two 
Summits a year?

-- Ed Leafe


signature.asc
Description: Message signed with OpenPGP
__
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-13 Thread Ed Leafe
On Dec 13, 2017, at 4:31 PM, Doug Hellmann <d...@doughellmann.com> wrote:

> You're missing the key point that coupled with the change in the
> overall development cycle schedule we would be encouraging projects
> to release more often.  I'd personally rather do away with milestones
> altogether and just tag everything monthly, but some projects may
> not be ready to do that and some may want to go more often (libraries
> in particular).

I think you're missing the reality that intermediate releases have about zero 
uptake in the real world. We have had milestone releases of Nova for years, but 
I challenge you to find me one non-trivial deployment that uses one of them. To 
my knowledge, based on user surveys, it is only the major 6-month named 
releases that are deployed, and even then, some time after their release.

Integrated releases make sense for deployers. What does it mean if Nova has 
some new stuff, but it requires a new release from Cinder in order to use it, 
and Cinder hasn't yet released the necessary updates? Talking about releasing 
projects on a monthly-tagged basis just dumps the problem of determining what 
works with the rest of the codebase onto the deployers.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-13 Thread Ed Leafe
On Dec 13, 2017, at 12:13 PM, Tim Bell <tim.b...@cern.ch> wrote:

> There is a risk that deployment to production is delayed, and therefore 
> feedback is delayed and the wait for the ‘initial bug fixes before we deploy 
> to prod’ gets longer.

There is always a rush at the Feature Freeze point in a cycle to get things in, 
or they will be delayed for 6 months. With the year-long cycle, now anything 
missing Feature Freeze will be delayed by a year. The long cycle also means 
that a lot more time will be spent backporting things to the current release, 
since people won’t be able to wait a whole year for some improvements.

Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).


-- Ed Leafe






__
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] [api] APAC-friendly API-SIG meeting times

2017-12-12 Thread Ed Leafe
Re-sending this in the hope of getting more responses. If you’re in the APAC 
region and interested in contributing to our discussions, please indicate your 
preferences on the link below.

>> That brought up another issue: the current meeting time for the API-SIG is 
>> 1600UTC, which is not very convenient for APAC contributors. Gilles is in 
>> Australia, and so it was the middle of the night for him! As one of the 
>> goals for the API-SIG is to expand our audience and membership, edleafe 
>> committed to seeing if there is an available meeting slot at 2200UTC, which 
>> would be convenient for APAC, and still early enough for US people to 
>> attend. If an APAC-friendly meeting time would be good for you, please keep 
>> an eye out on the mailing list for an announcement if we are able to set 
>> that up, and then please attend and participate!
> 
> Looking at the current meeting schedule, there are openings at 2200UTC  on 
> Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
> Wednesday afternoons in the US). 
> 
> I’ve set up a doodle so that people can record their preferences:
> 
> https://doodle.com/poll/bec9gfff38zvh3ud
> 
> If you’re interested in attending API-SIG meetings, please fill out the form 
> at that URL with your preferences. I’ll summarize the results at the next 
> API-SIG meeting.
> 
> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> 
> __
> 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


-- Ed Leafe






__
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] [api] APAC-friendly API-SIG meeting times

2017-12-07 Thread Ed Leafe
On Dec 7, 2017, at 11:22 AM, Ed Leafe <e...@leafe.com> wrote:

> That brought up another issue: the current meeting time for the API-SIG is 
> 1600UTC, which is not very convenient for APAC contributors. Gilles is in 
> Australia, and so it was the middle of the night for him! As one of the goals 
> for the API-SIG is to expand our audience and membership, edleafe committed 
> to seeing if there is an available meeting slot at 2200UTC, which would be 
> convenient for APAC, and still early enough for US people to attend. If an 
> APAC-friendly meeting time would be good for you, please keep an eye out on 
> the mailing list for an announcement if we are able to set that up, and then 
> please attend and participate!

Looking at the current meeting schedule, there are openings at 2200UTC  on 
Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
Wednesday afternoons in the US). 

I’ve set up a doodle so that people can record their preferences:

https://doodle.com/poll/bec9gfff38zvh3ud

If you’re interested in attending API-SIG meetings, please fill out the form at 
that URL with your preferences. I’ll summarize the results at the next API-SIG 
meeting.


-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2017-12-07 Thread Ed Leafe
Greetings OpenStack community,

A good meeting this week [5], with the discussion centered mostly on a spec for 
an API-schema guide [8]. The spec itself isn't quite fleshed out enough, so it 
wasn't entirely clear what problem this would be adressing. The spec's author, 
Gilles, will add additional information to the spec and we will re-review.

That brought up another issue: the current meeting time for the API-SIG is 
1600UTC, which is not very convenient for APAC contributors. Gilles is in 
Australia, and so it was the middle of the night for him! As one of the goals 
for the API-SIG is to expand our audience and membership, edleafe committed to 
seeing if there is an available meeting slot at 2200UTC, which would be 
convenient for APAC, and still early enough for US people to attend. If an 
APAC-friendly meeting time would be good for you, please keep an eye out on the 
mailing list for an announcement if we are able to set that up, and then please 
attend and participate!

* The list of bugs [6] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [7] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [7].

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

* WIP: Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] 
http://eavesdrop.openstack.org/meetings/api_sig/2017/api_sig.2017-12-07-16.01.log.html
[6] https://bugs.launchpad.net/openstack-api-wg
[7] https://git.openstack.org/cgit/openstack/api-wg
[8] https://review.openstack.org/#/c/524467/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2017-11-16 Thread Ed Leafe
Greetings OpenStack community,

No meeting this week, as people are still straggling back after the Sydney 
summit. There will also be no meeting next week, due to the US Thanksgiving 
holiday. So I guess we'll see you all again in December!

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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] [ironic] [nova] traits discussion call - moved to Tue!!

2017-11-02 Thread Ed Leafe
On Nov 2, 2017, at 4:17 AM, Dmitry Tantsur <dtant...@redhat.com> wrote:
> 
> The recording of the call is https://bluejeans.com/s/K3wZZ

Ugh: "To watch the video, you need Adobe Flash Player 10.1 or higher"


-- Ed Leafe






__
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][ironic] Concerns over rigid resource class-only ironic scheduling

2017-10-26 Thread Ed Leafe
On Oct 26, 2017, at 6:57 PM, Wan-yen Hsu <wanyen...@gmail.com> wrote:

> In Nisha's message, "capabilities" refers to "ComputeCapabilitiesFilter".   
> "capabilities" provides a lot of flexibility for scheduling.  It supports 
> qualitative as well as quantitative attributes.  It supports a variety of 
> operators such as ">=", "<", "=", etc.   For instance, with "capabilities", 
> one can create a flavor for "GPU_Count >=2".  Quantity matters for workloads. 
>  A workload may require at least 2GPUs or at least certain amount of SSD 
> capacity to meet the performance requirements.   Trait will help but it only 
> supports qualitative attributes.  Therefore, we still need "capabilities".

In your example, you would create a resource class that specifies the number of 
GPUs. If there is a machine with no GPU, it would be a different resource class 
than a machine with a GPU. Likewise, a machine with 2 GPUs would be a different 
class. This gives you the ability to match the request to the need. Saying you 
need a machine with at least 2 GPUs means that you could end up with a machine 
with 100 GPUs - ok, I know that's not realistic, but it illustrates my point. 
Each hardware combination is a separate resource class. If your workload 
requires 2 GPUs and SSD, there are a finite number of hardware combinations 
available. You pick the flavor (i.e., resource class) that matches your need.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [elections] Technical Committee Election Results

2017-10-26 Thread Ed Leafe
On Oct 26, 2017, at 9:52 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> 
> It would also be good to see some discussion of those issues outside
> of campaign periods. Some of the questions, like the one about user
> perspectives held by the candidates, were clearly meant to elicit
> more info to help make a choice in the election. The discussion of
> inclusiveness shouldn't be reserved for the campaign period, though.

Very true, but it’s nice to see the candidates’ answers collected in a single 
place. I know that I don’t have the time to search through meeting and IRC 
archives to find the answers for the people I am considering voting for.

-- Ed Leafe






__
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] [elections] Technical Committee Election Results

2017-10-26 Thread Ed Leafe
On Oct 25, 2017, at 10:36 PM, Tony Breeds <t...@bakeyournoodle.com> wrote:

> The whole election takes close to 3 weeks of officials time so I'd like
> to ask we be mindful of that before we extend things too much

There isn’t really a need for the self-nomination period to be very long. 
Announce it, say, a week before nominations open, and give candidates a few 
days to post their nominations. History has shown that the majority of 
candidates announce near the end of the period, and as a former nominee, I can 
say that a lot of that was due to procrastination.

I was glad to see a good response to the questions this time, and the answers 
(and non-answers) strongly influenced my vote. So I would rather see a shorter 
nomination period and a longer “campaign” period in the future.


-- Ed Leafe






__
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] [all][api] POST /api-sig/news

2017-10-19 Thread Ed Leafe
Greetings OpenStack community,

If you were hoping for startling news, well, you're going to be disappointed. 
We did, however, have a perfectly enjoyable meeting today.

A question had been raised about creating a guideline for 'changes-since' 
filtering in an API [5], and we debated whether it was needed or not. Consensus 
is that while it isn't of critical importance, it is something that we should 
add to the guidelines on filtering to help achieve consistency across APIs. 
edleafe volunteered to tackle that when he has some free time. The mention of 
"free time" brought much hilarity to everyone at the meeting.

* There's been some discussion of recording an outreach video at summit. 
edleafe sent an email to the openstack-sigs mailing list [7], but so far there 
has been no reply. If there is still no response in a few days, a reminder 
email will be sent.

elmiko posted an email to the openstack-sigs mailing list [7] to help find out 
if there is any interest in an alternate time for holding the API-SIG IRC 
meeting in order to accommodate APAC contributors. As this was just sent, there 
is no response yet. We also expressed the idea that email is probably better 
for communication across time zones than alternating meetings.

# Newly Published Guidelines

* Updates for rename to SIG
  https://review.openstack.org/#/c/508242/
  While this isn't technically a guideline, it is an important step in our 
transition from a WG to a SIG.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] 
http://p.anticdent.org/logs/openstack-nova?dated=2017-10-16%2022:04:06.467386#15H4
[6] http://lists.openstack.org/pipermail/openstack-sigs/
[7] http://lists.openstack.org/pipermail/openstack-sigs/2017-October/000127.html

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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][tc] TC Candidates: what does an OpenStack user look like?

2017-10-13 Thread Ed Leafe
On Oct 13, 2017, at 2:21 PM, Zane Bitter <zbit...@redhat.com> wrote:

> All sarcasm aside though, 'everyone' is a BS non-answer. It's the 
> politician's answer.
> 
> Not only because engineering trade-offs are a real thing, and some use cases 
> will *definitely* be excluded in order to better serve others, but because 
> the average user doesn't exist. If you design for the 'average' user then you 
> are designing for nobody, because nobody is the average user. We shouldn't be 
> designing for 'everybody' (aka nobody in particular), but for a large variety 
> of somebodies.

I wish all candidates, not just TC candidates, got follow-up questions like 
this. Bravo, Zane!


-- Ed Leafe






__
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][election] Question for the candidates

2017-10-12 Thread Ed Leafe
On Oct 12, 2017, at 8:10 PM, Mohammed Naser <mna...@vexxhost.com> wrote:

> I think that the OpenStack infrastructure team is doing a wonderful
> job at keeping such a huge CI system working to the best of their
> effort, however, I think that there needs to be a stronger
> relationship between projects and the infrastructure team in order for
> us to help alleviate some of the load that is on them. There are a lot
> of moving components from dealing with multiple cloud infrastructure
> donors, operating two flavours of clouds internally, maintaining the
> codebase of Zuul and other system administration related tasks.

Thanks for the answer, and I definitely agree. But I don't feel that you 
answered the important part: what would you have wanted the TC to do about this?

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [tc][election] Question for the candidates

2017-10-12 Thread Ed Leafe
In the past year or so, has there been anything that made you think “I wish the 
TC would do something about that!” ? If so, what was it, and what would you 
have wanted the TC to do about it?

-- Ed Leafe






__
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] [placement] resource providers update 36

2017-10-06 Thread Ed Leafe
On Oct 6, 2017, at 8:21 AM, Chris Dent <cdent...@anticdent.org> wrote:

> The extent to which an
> allocation request is not always opaque and the need to be explicit
> about microversions was clarified, so edleafe is going to make some
> adjustments, after first resolving the prerequisite code (alternate
> hosts: https://review.openstack.org/#/c/486215/ ).

For the record, what was clarified was that the agreement that the 
allocation_request blob that had been previously agreed to as an opaque blob 
had been compromised by some last-minute hacks to get migrations working before 
the Pike deadline. As a result of this change, it was now necessary to add 
versioning to these allocation_request objects, because now Nova or any other 
service could be altering them as they saw fit. I still think that this is a 
terrible design, but I will bow to the pressure to go along with accommodating 
the change to the previous design.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [all][api] POST /api-sig/news

2017-09-28 Thread Ed Leafe
Greetings OpenStack community,

It was a quiet meeting this week, probably due to elmiko being absent. And 
probably also due to cdent and edleafe being consumed by work outside of the 
SIG. We did note that we are looking forward to our expanded role with the 
addition of the SDK developers into the SIG, but so far not much has happened 
along these lines.

# Newly Published Guidelines

None

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






__
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-operators] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

2017-09-14 Thread Ed Leafe
On Sep 14, 2017, at 10:30 AM, melanie witt <melwi...@gmail.com> wrote:
> 
> I was thinking, if it's possible to assign more than one resource class to an 
> Ironic node, maybe you could get similar behavior to the old non-exact 
> filters. So if you have an oddball config, you could tag it as multiple 
> resource classes that it's "close enough" to for a match. But I'm not sure 
> whether it's possible for an Ironic node to be tagged with more than one 
> resource class.

On the placement side, having an ironic node with two resource classes such as 
RC1 and RC2, would mean that the ResourceProvider (the ironic node) would have 
two inventory records: one for RC1, and another for RC2. When a request for a 
flavor specifying one of these classes is handled, only the one class’s 
inventory would be consumed. Placement would think that the node still had one 
of the other resource class available, and would include that if another 
request for that class is received, which would then fail as the node is 
already in use.

-- Ed Leafe






__
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] [placement] Modeling SR-IOV with nested resource providers

2017-09-06 Thread Ed Leafe
On Sep 5, 2017, at 10:02 AM, Andrey Volkov <avol...@mirantis.com> wrote:

> For example, I have SR-IOV PF with four ports (P_i), two of them are
> connected to one switch (SW_1) and other two to another (SW_2). I
> would like to get VFs from distinct ports connected to distinct
> switches (more details can be found in spec [1]), how it can be
> modeled with nested resource providers?

You should make it as complicated as it needs to be, but no more. The first 
model nests one deep, while the second goes two levels deep, yet they both 
provide the same granularity for accessing the VFs, so I would go for the 
first. And I’m not sure that we will be able to get the “inherited” traits used 
in the second model implemented any time soon.

-- Ed Leafe






__
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] placement/resource providers update 29

2017-08-07 Thread Ed Leafe
On Jul 24, 2017, at 5:05 AM, Chris Dent <cdent...@anticdent.org> wrote:
> 
> I guess the code that Ed's working on at
> 
>https://review.openstack.org/#/c/484949
> 
> need to zero out VCPU etc in the extra specs so that the eventual
> allocation record is created in 484935 is correct?

That’s what I thought, too, but apparently [0] we need both in Pike. The 
zeroing out can’t happen until Queens.

[0] https://review.openstack.org/#/c/484949/2/nova/virt/ironic/driver.py@471

-- Ed Leafe






__
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] [all][api] POST /api-wg/news

2017-08-03 Thread Ed Leafe
Greetings OpenStack community,

Today's meeting started off with continued discussion about the Guided Review 
process that we are trying to create ahead of the Denver PTG, where we would 
like to incorporate such a process as part of our sessions. This has been 
crystallized into a document [0] by elmiko. One point that is still to be added 
is how we record discussions after the fact, so that they can be preserved and 
referenced in the future.

The bulk of the meeting was taken up in discussing the proposed change from a 
Working Group (WG) to a Special Interest Group (SIG). This is in response to 
Thierry Carrez's email [4] on the subject. No one had any particularly strong 
feelings either way; I mean, we want to be as useful as possible to as many 
people as possible, but it's simply not clear whether the change to being a SIG 
would a) make that easier, or b) make that more difficult, or c) have no 
effect. In our case, this is also complicated by the fact that we are small, 
and expanding to a wider audience might be too much. Or it may bring in lots of 
new people to help out. We really don't know. We will continue to discuss this 
on the mailing list and future meetings.

There are no new guidelines for this week, but a small update to an existing 
document [5] was merged.


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] https://review.openstack.org/#/c/487847/
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] http://lists.openstack.org/pipermail/openstack-sigs/2017-July/22.html
[5] https://review.openstack.org/#/c/487504/

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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][tc] How to deal with confusion around "hosted projects"

2017-07-14 Thread Ed Leafe
On Jul 14, 2017, at 2:17 PM, Zane Bitter <zbit...@redhat.com> wrote:

> * The pool of OpenStack developers is a fixed resource, and if we make it 
> clear that some projects are unwelcome then their developers will be 
> reassigned to 'core' projects in a completely zero-sum process. (Nnope.)

Yeah, I’ve heard this many times, and always shake my head. If I want to work 
on X, and X is not in OpenStack governance, I’m going to work on that anyway 
because I need it. Or maybe on a similar project. I’m going to scratch my itch.

> * While code like e.g. the Nova scheduler might be so complicated today that 
> even the experts routinely complain about its terrible design,[1] if only we 
> could add dozens more cooks (see above) it would definitely get much simpler 
> and easier to maintain. (Bwahahahahahahaha.)

No, they need to appoint me as the Scheduler Overlord with the power to smite 
all those who propose complicated code!

> * Once we make it clear to users that under no circumstances will we ever 
> e.g. provide them with notifications about when a server has failed, ways to 
> orchestrate a replacement, and an API to update DNS to point to the new one, 
> then they will finally stop demanding bloat-inducing VMWare/oVirt-style 
> features that enable them to treat cloud servers like pets. (I. don't. even.)


Again, itches will be scratched. What I think is more important is a marketing 
issue, not a technical one. When I think of what it means to be a “core” 
project, I think of things that people looking to “get cloudy” would likely 
want. It isn’t until you start using a cloud that the additional projects you 
mention become important. So simplifying what is presented to the cloud market 
is a good thing, as it won’t confuse people as to what OpenStack is. But that 
doesn’t require any of the other projects be stopped or in any way discouraged.

-- Ed Leafe





__
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][tc] How to deal with confusion around "hosted projects"

2017-07-14 Thread Ed Leafe
On Jul 13, 2017, at 10:32 PM, Fei Long Wang <feil...@catalyst.net.nz> wrote:

> I agree with Zane for most of the parts. But one thing I don't really
> understand is, why OpenStack community is still confusing at the IaaS,
> PaaS and SaaS, does the classification really mater at nowadays? Do we
> really need a label/tag for OpenStack to limit it as an IaaS, PaaS or
> SaaS? I never see AWS says it's an IaaS, PaaS or SaaS. Did Azure or
> Google Cloud say that? I think they're just providing the service their
> customer want.

Sure, they may not distinguish those things publicly, but in their internal 
development teams it is very likely that they understand these boundaries. And 
just for another quick example, from the Azure site:

https://azure.microsoft.com/en-us/overview/azure-vs-aws/

"We are the only cloud provider recognized in the industry as having leading 
solutions in IaaS, PaaS, and SaaS. And Azure PaaS platform services can help 
you be more productive and increase your ROI according to this Forrester Total 
Economic Impact study.”

So I don’t think that this distinction is peculiar to OpenStack.

-- Ed Leafe






__
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] [all][api] POST /api-wg/news

2017-07-13 Thread Ed Leafe
Greetings OpenStack community,

If you missed our meeting today, well, you didn't miss much. Not a lot of new 
things going on. The bulk of the meeting was taken up with ideas for what we'd 
like to accomplish at the upcoming Denver PTG. We thought that it might be 
useful to have an informal "what do you think about our API" session, where 
people from various projects could bring up issues they are concerned about in 
their APIs, and we could then discuss what might be a better approach. The 
initial idea isn't to force anything, but rather to have these discussions 
*before* an API is released, so that there might be fewer problems later on. 
These are still initial working ideas, so we agreed to think this through a bit 
more before next week's meeting. If you have ideas, please let the group know.

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] Should PUT /os-services be idempotent?

2017-07-11 Thread Ed Leafe
On Jul 11, 2017, at 8:18 PM, Matt Riedemann <mriede...@gmail.com> wrote:

> With the old APIs, if you tried to enable and already enabled service, it was 
> not an error. The same is you tried to disable an already disabled service. 
> It doesn't change anything, but it's not an error.
> 
> The question is coming up in the new API if trying to enable an enabled 
> service should be a 400, or trying to disable a disabled service. The way I 
> wrote the new API, those are no 400 conditions. They don't do anything, like 
> before, but they aren't errors.

These should not be errors. You are calling the API to set a particular 
condition. The result of that call is that the service is in that condition. 
That should be a 2xx, most likely a 204. So yeah, it should be idempotent.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [Glare][TC] Application for inclusion of Glare in the list of official projects

2017-07-10 Thread Ed Leafe
On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin <mfedo...@gmail.com> wrote:

> Given all the advantages and features of Glare, I believe that it can become 
> the successful drop-in replacement.


Can you clarify this? Let’s assume I have a decent-sized deployment running 
Glance. If I were to remove Glance and replace it with Glare, are you saying 
that nothing would break? Operators, users, scripts, SDKs, etc., would all work 
unchanged?

-- Ed Leafe





__
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][tc] Moving away from "big tent" terminology

2017-06-15 Thread Ed Leafe
On Jun 15, 2017, at 3:35 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> For me it's one of the most annoying yet challenging/interesting
> aspects: free software development is as much about community and
> politics as it is actual software development (perhaps more so).

Another way to look at it is how we see ourselves (as a community) and how 
people on the outside see OpenStack. I would imagine that someone looking at 
OpenStack for the first time would not care a whit about governance, repo 
locations, etc. They would certainly care about "what do I need to do to use 
this thing?"

What we call things isn't confusing to those of us in the community - well, at 
least to those of us who take the time to read big long email threads like 
this. We need to be clearer in how we represent OpenStack to outsiders. To that 
end, I think that limiting the term "OpenStack" to a handful of the core 
projects would make things a whole lot clearer. We can continue to present 
everything else as a marketplace, or an ecosystem, or however the more 
marketing-minded want to label it, but we should *not* call those projects 
"OpenStack".

Now I know, I work on Nova, so I'm expecting responses that "of course you 
don't care", or "OpenStack is people, and you're hurting our feelings!". So 
flame away!

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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][scheduler][placement] Allocating Complex Resources

2017-06-09 Thread Ed Leafe
On Jun 9, 2017, at 4:35 PM, Jay Pipes <jaypi...@gmail.com> wrote:

>> We can declare that allocating for shared disk is fairly deterministic
>> if we assume that any given compute node is only associated with one
>> shared disk provider.
> 
> a) we can't assume that
> b) a compute node could very well have both local disk and shared disk. how 
> would the placement API know which one to pick? This is a sorting/weighing 
> decision and thus is something the scheduler is responsible for.

I remember having this discussion, and we concluded that a compute node could 
either have local or shared resources, but not both. There would be a trait to 
indicate shared disk. Has this changed?

>> * We already have the information the filter scheduler needs now by
>>  some other means, right?  What are the reasons we don't want to
>>  use that anymore?
> 
> The filter scheduler has most of the information, yes. What it doesn't have 
> is the *identifier* (UUID) for things like SRIOV PFs or NUMA cells that the 
> Placement API will use to distinguish between things. In other words, the 
> filter scheduler currently does things like unpack a NUMATopology object into 
> memory and determine a NUMA cell to place an instance to. However, it has no 
> concept that that NUMA cell is (or will soon be once 
> nested-resource-providers is done) a resource provider in the placement API. 
> Same for SRIOV PFs. Same for VGPUs. Same for FPGAs, etc. That's why we need 
> to return information to the scheduler from the placement API that will allow 
> the scheduler to understand "hey, this NUMA cell on compute node X is 
> resource provider $UUID".

I guess that this was the point that confused me. The RP uuid is part of the 
provider: the compute node's uuid, and (after 
https://review.openstack.org/#/c/469147/ merges) the PCI device's uuid. So in 
the code that passes the PCI device information to the scheduler, we could add 
that new uuid field, and then the scheduler would have the information to a) 
select the best fit and then b) claim it with the specific uuid. Same for all 
the other nested/shared devices.

I don't mean to belabor this, but to my mind this seems a lot less disruptive 
to the existing code.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [nova][scheduler][placement] Allocating Complex Resources

2017-06-05 Thread Ed Leafe
We had a very lively discussion this morning during the Scheduler subteam 
meeting, which was continued in a Google hangout. The subject was how to handle 
claiming resources when the Resource Provider is not "simple". By "simple", I 
mean a compute node that provides all of the resources itself, as contrasted 
with a compute node that uses a shared storage for disk space, or which has 
complex nested relationships with things such as PCI devices or NUMA nodes. The 
current situation is as follows:

a) scheduler gets a request with certain resource requirements (RAM, disk, CPU, 
etc.)
b) scheduler passes these resource requirements to placement, which returns a 
list of hosts (compute nodes) that can satisfy the request.
c) scheduler runs these through some filters and weighers to get a list ordered 
by best "fit"
d) it then tries to claim the resources, by posting to placement allocations 
for these resources against the selected host
e) once the allocation succeeds, scheduler returns that host to conductor to 
then have the VM built

(some details for edge cases left out for clarity of the overall process)

The problem we discussed comes into play when the compute node isn't the actual 
provider of the resources. The easiest example to consider is when the computes 
are associated with a shared storage provider. The placement query is smart 
enough to know that even if the compute node doesn't have enough local disk, it 
will get it from the shared storage, so it will return that host in step b) 
above. If the scheduler then chooses that host, when it tries to claim it, it 
will pass the resources and the compute node UUID back to placement to make the 
allocations. This is the point where the current code would fall short: 
somehow, placement needs to know to allocate the disk requested against the 
shared storage provider, and not the compute node.

One proposal is to essentially use the same logic in placement that was used to 
include that host in those matching the requirements. In other words, when it 
tries to allocate the amount of disk, it would determine that that host is in a 
shared storage aggregate, and be smart enough to allocate against that 
provider. This was referred to in our discussion as "Plan A".

Another proposal involved a change to how placement responds to the scheduler. 
Instead of just returning the UUIDs of the compute nodes that satisfy the 
required resources, it would include a whole bunch of additional information in 
a structured response. A straw man example of such a response is here: 
https://etherpad.openstack.org/p/placement-allocations-straw-man. This was 
referred to as "Plan B". The main feature of this approach is that part of that 
response would be the JSON dict for the allocation call, containing the 
specific resource provider UUID for each resource. This way, when the scheduler 
selects a host, it would simply pass that dict back to the /allocations call, 
and placement would be able to do the allocations directly against that 
information.

There was another issue raised: simply providing the host UUIDs didn't give the 
scheduler enough information in order to run its filters and weighers. Since 
the scheduler uses those UUIDs to construct HostState objects, the specific 
missing information was never completely clarified, so I'm just including this 
aspect of the conversation for completeness. It is orthogonal to the question 
of how to allocate when the resource provider is not "simple".

My current feeling is that we got ourselves into our existing mess of ugly, 
convoluted code when we tried to add these complex relationships into the 
resource tracker and the scheduler. We set out to create the placement engine 
to bring some sanity back to how we think about things we need to virtualize. I 
would really hate to see us make the same mistake again, by adding a good deal 
of complexity to handle a few non-simple cases. What I would like to avoid, no 
matter what the eventual solution chosen, is representing this complexity in 
multiple places. Currently the only two candidates for this logic are the 
placement engine, which knows about these relationships already, or the compute 
service itself, which has to handle the management of these complex virtualized 
resources.

I don't know the answer. I'm hoping that we can have a discussion that might 
uncover a clear approach, or, at the very least, one that is less murky than 
the others.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [all][api] POST /api-wg/news

2017-06-01 Thread Ed Leafe
Greetings OpenStack community,

A very lively meeting today, with all the participants in a seemingly jovial 
mood. Must be something in the water. Or maybe June just brings out 
lightheartedness.

Much of the discussion centered on Monty Taylor's chain of patches [4] 
regarding version discovery and the service catalog. No controversy about them, 
but some grumbling over the sheer volume of content. This isn't a complaint; 
rather, I think we are in awe of the size of the brain dump as Monty shares his 
accumulated knowledge. We can use some help reviewing these, so that they are 
as understandable as such esoteric material can possibly be.

We also discussed the proposed change to the microversions guideline about how 
to signal an upcoming raising of the minimum version [5]. There was agreement 
that having such a signal was a good thing, but there is still some confusion 
about how to communicate when this change will happen. The idea is that it 
isn't enough to say that it's going to be raised; it's also important to 
communicate how long a user has to update their code to handle this raising. We 
came up with adding a field that states the earliest possible date of the 
change, with the understanding that it could happen later than that. This was 
to help users get an idea of the urgency of the change. So while we can agree 
on that, as usual it is the naming of the field that is problematic. The 
current choice is 'not_raise_min_before', but we're open to improvements. Let 
the bikeshedding begin!

# Newly Published Guidelines

Nothing new at this time.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at this time but please check out the reviews below.

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* A suite of several documents about using the service catalog and doing 
version discovery
  Start at https://review.openstack.org/#/c/462814/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] Start at https://review.openstack.org/#/c/462814/
[5] https://review.openstack.org/#/c/446138/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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][ironic][mogan][nova] mogan and nova co-existing

2017-05-30 Thread Ed Leafe
On May 30, 2017, at 9:36 PM, Zhenguo Niu <niu.zgli...@gmail.com> wrote:

> as placement is not splitted out from nova now, and there would be users who 
> only want a baremetal cloud, so we don't add resources to placement yet, but 
> it's easy for us to turn to placement to match the node type with mogan 
> flavors.

Placement is a separate service, independent of Nova. It tracks Ironic nodes as 
individual resources, not as a "pretend" VM. The Nova integration for selecting 
an Ironic node as a resource is still being developed, as we need to update our 
view of the mess that is "flavors", but the goal is to have a single flavor for 
each Ironic machine type, rather than the current state of flavors pretending 
that an Ironic node is a VM with certain RAM/CPU/disk quantities.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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][ironic][mogan][nova] mogan and nova co-existing

2017-05-30 Thread Ed Leafe
On May 30, 2017, at 9:08 PM, Zhenguo Niu <niu.zgli...@gmail.com> wrote:

> There would be a collision if nova and mogan consume the same ironic nodes 
> cluster, as both of them will see all the available node resources. So if 
> someone wants to choose mogan for baremetal compute management, the 
> recommended deployment is Mogan+Ironic for baremetals and Nova+Libvirt for 
> VMs, this way we treat baremetals and vms as different compute resources. In 
> a cloud with both vms and baremetals, it's more clear to have different set 
> of APIs to manage them if users really care about what resources they got 
> instead of just the performance. We also create a mogan horizon plugin which 
> adds separated baremetal servers panel[1].

So Mogan does not use the placement service for tracking resources?


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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 Ed Leafe
On May 16, 2017, at 3:06 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> 
>> It's pretty clear now some see drawbacks in reusing #openstack-dev, and
>> so far the only benefit expressed (beyond not having to post the config
>> change to make it happen) is that "everybody is already there". By that
>> rule, we should not create any new channel :)
> 
> That was not the only concern expressed. It also silos us away from
> the community who has elected us to represent them, potentially
> creating another IRC echo chamber.

Unless you somehow restrict access to the channel, it isn't much of a silo. I 
see TC members in many other channels, so it isn't as if there will be no 
interaction between TC members and the community that they serve.

I also think that a channel like #openstack-tc is more discoverable to people 
who might want to interact with the TC, as it follows the same naming 
convention as #openstack-nova, #openstack-ironic, etc.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] TC Report 18

2017-05-03 Thread Ed Leafe
On May 3, 2017, at 2:41 AM, Thierry Carrez <thie...@openstack.org> wrote:

> In the current
> system, TC members (or really, anyone in the community) can add to the
> "Open discussion" section of the meeting agenda, but that happens
> extremely rarely. I suspect that the 5 minutes per week that we end up
> dedicating to open discussion in the meetings does not encourage people
> to load large topics of discussions in it.

Simple: *start* the meeting with Open Discussion.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [all][api] POST /api-wg/news

2017-04-20 Thread Ed Leafe
Greetings OpenStack community,

A bit of a lonely meeting today, as only cdent and edleafe were present for 
most of it, although having elmiko join at the end brightened all of our days. 
The main item of discussion was the status of the various project liaisons to 
the API WG [0], and how to handle that. edleafe agreed to ping the current 
liaisons to get an update as to their status.

Due to the lack of feeback from the liaisons, we agreed to postpone merging the 
three frozen guidelines for another week to make sure that there are no 
objections. After all, it was Easter and all, so perhaps lots of people are in 
chocolate-induced comas.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Define pagination guidelines
  https://review.openstack.org/#/c/446716/

* Create a set of api interoperability guidelines
  https://review.openstack.org/#/c/421846/

* Recommend the correct HTTP method for tags
  https://review.openstack.org/451536

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
  https://review.openstack.org/#/c/447344/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/
  On hold.

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-April/115723.html
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-13 Thread Ed Leafe
On Apr 11, 2017, at 9:54 PM, joehuang <joehu...@huawei.com> wrote:

> Can all these efforts lead us to one platform vision? We have to think over 
> the question.
> 
> What's the one platform will be in your own words? What's your proposal and 
> your focus to help one platform vision being achieved?

I think the word "platform" is critical here. OpenStack is not a single "thing" 
that everyone can use the same way. It's a collection of pieces that work 
together to help solve many different workloads. The key to that is having a 
solid base and consistent interfaces among the various projects to create a 
platform that solutions can be built upon.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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][election] Questions for Candidates

2017-04-12 Thread Ed Leafe
On Apr 12, 2017, at 11:19 AM, Kendall Nelson <kennelso...@gmail.com> wrote:

> -What is one trait you have that makes it difficult to work in groups like 
> the TC and how do you counteract it?

My natural tendency is to speak bluntly, which can often come across as 
dismissive of other points of view. As I've gotten older I've learned a few 
tricks to soften my words, but it's a constant effort.

> - What do you see as the biggest roadblock in the upcoming releases for the 
> TC?

The pull of corporate interests, both to steer development in directions that 
will benefit their business, and also by pulling developers off of OpenStack 
work. Neither of these is new, but they certainly seem to be increasing lately 
with no sign of letting up.

> And one lighthearted question:
> 
> -What is your favorite thing about OpenStack?

I'm sure everyone will write pretty much the same thing here: the community, 
getting to interact with so many talented and interesting people. Because it 
certainly is! So I'll throw in my *second* favorite thing: being a part of 
creating something that can change the world of computing. It's already played 
a role in the discovery of the Higgs boson, and I'm sure that someday it will 
enable technologies that haven't yet been dreamed up. Being able to look back 
someday and say "I helped to build that" will be pretty satisfying.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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 Ed Leafe
On Apr 12, 2017, at 9:44 AM, gordon chung <g...@live.ca> wrote:

>> 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 ?
> 
> this is a really good question! if we're all honest with ourselves, most
> of the rhetoric in the self-nominations are far to grand to be
> accomplished in multiple terms let alone one term which is normal for
> campaigning. it's good to consider what you would consider a success at
> the end of your term(s), whether or you succeed at it or not (i swear
> i'm not a manager).

Very good point. In my case, I presented the goal, knowing that at best I might 
be able to nudge the OpenStack world a bit closer in that direction.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-11 Thread Ed Leafe
On Apr 11, 2017, at 12:48 PM, Jay Pipes <jaypi...@gmail.com> wrote:

>>  The IaaS parts
>> (and yes, I know that just which parts these are is a whole debate in
>> itself) should be rock-solid, slow-moving, and, well, boring.
> 
> A fine idea. Unfortunately, what the majority of end users keep asking for is 
> yet more features, especially features that expose more and more internals of 
> the infrastructure and hardware to the power user (admin or orchestrator).

And they always will. But my point was that those things should be added 
without causing the existing system to become unstable. Stability of the 
foundation allows for much more interesting things to be built on top.

> This is *precisely* what the Big Tent was all about:

Totally agree! The key word, unfortunately, is "was". I don't believe that we 
have seen the results to the degree that we envisioned.

I would add that it isn't simply the choice of tools or language, but also 
their API. Monasca had an uphill struggle because some of their API overlapped 
with other projects, especially Ceilometer. Never mind that it might offer a 
better solution than something like Ceilometer; since Ceilometer was there 
first, Monasca  I would prefer to see these projects be free to develop good, 
solid APIs, and if there is functional overlap or API overlap, so be it. This 
avoids the "first one wins" hurdle. Let each project stand on their own merits. 
If it isn't better than what already exists, no one will use it and it will 
wither away. But if it is better, then that makes our ecosystem that much 
richer.

>> > Such projects will also have to accept a tag such as
>> 'experimental' or 'untested' until they can demonstrate otherwise.
> 
> This already exists, in a much more fine-grained fashion, as originally 
> designed into the concept of the Big Tent:
> 
> https://governance.openstack.org/tc/reference/tags/index.html
> 
> Are you just recommending that the TC controls more of those tags?


Yes! One of the thing that was painful to watch in the tag development process 
was the strong aversion to saying anything that might be considered negative 
about a project, as if stating that, say, a project wasn't fully tested would 
hurt someone's feelings. A more open development environment will require such 
technical evaluations, and not all will be positive. The TC should definitely 
work on making this happen.

>> This can also serve to encourage the development of additional
>> testing resources around, say, Golang projects, so that the Golang
>> community can all pitch in and develop the sort of infrastructure
>> needed to adequately test their products, both alone and in
>> conjunction with the IaaS core of OpenStack. The only thing that
>> should be absolute is a project's commitment to the Four Opens. There
>> will be winners, and there will be losers, and that's not only OK,
>> it's how it should be.
> 
> I'm not grasping how the above doesn't already represent the state of the 
> OpenStack governance world?

It's a matter of emphasis. There wasn't any governance that said that a 
project's API can't overlap with an existing project, but that was the message 
that the TC sent to Monasca. This should be changed to a positive statement 
about encouraging competition and new approaches. I'd like the Four Opens to 
remain an absolute, but that's about it. Duplicated effort? Solving the same or 
a similar problem as another project? Those things shouldn't matter (outside of 
the IaaS core projects). Teams should be free to decide if working with another 
team is the best approach, or going it alone, for example.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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 Ed Leafe
On Apr 10, 2017, at 3:40 PM, Matt Riedemann <mriede...@gmail.com> wrote:
> 
> I don't attend many TC meetings, it's usually on accident, but yeah, when I 
> do I always note the flurry of cross-talk chatter that just drowns everything 
> out. I feel like there are usually at least 3 parallel conversations going on 
> during a TC meeting and it's pretty frustrating to follow along, or get a 
> thought in the mix. That has to be much worse for a non-native English 
> speaker.
> 
> So yeah, slow down folks. :)

When there are topics with a lot of people clamoring to talk, Thierry usually 
lets people speak in order of "raising their hand". This reduces cross-talk and 
lets everyone get their turn to state what's on their mind. Normally, though, 
it is a bit of an acquired skill to be able to follow along.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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 Ed Leafe
On 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) ?

Well, as you know I have been active with the TC for years now, even though 
I've never been elected to a position on the TC. Since so many of the issues 
that the TC deals with are important to OpenStack's future, I like to 
contribute to bettering that wherever I can. So if elected to serve on the TC, 
I would be able to focus even more of my time, going from maybe 5-10% now, to 
50% if elected.

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

Just one? If I had to choose, I would like to see a clear separation between 
the core services that provide IaaS, and the products that then build on that 
core. They occupy very different places in the OpenStack picture, and should be 
treated differently. The IaaS parts (and yes, I know that just which parts 
these are is a whole debate in itself) should be rock-solid, slow-moving, and, 
well, boring. Reliability is the key for them. But for the services and 
applications that are built on top of this base? I'd like to see allowing them 
a much more open approach: let them develop in whatever language they like, 
release when they feel the timing is right, and define their own CI testing. In 
other words, if you want to develop in a language other than Python, go for it! 
If you want to use a particular NoSQL database, sure thing! However, the price 
of that freedom is that the burden will be on the project to ensure that it is 
adequately tested, instead of laying that responsibility on our infra team. 
Such projects will also have to accept a tag such as 'experimental' or 
'untested' until they can demonstrate otherwise. This can also serve to 
encourage the development of additional testing resources around, say, Golang 
projects, so that the Golang community can all pitch in and develop the sort of 
infrastructure needed to adequately test their products, both alone and in 
conjunction with the IaaS core of OpenStack. The only thing that should be 
absolute is a project's commitment to the Four Opens. There will be winners, 
and there will be losers, and that's not only OK, it's how it should be.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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-07 Thread Ed Leafe
Hello! I am once again announcing my candidacy for a position on the OpenStack 
Technical Committee.

For those who do not know me, I'm easy to find. My name is Ed Leafe; I'm 
'edleafe' on IRC, and @edleafe on Twitter. I have been involved with OpenStack 
since the very beginning, when I was working for Rackspace as a core member of 
the Nova team. An internal job change took me away from active development 
after Essex, but since being hired by IBM, I've been back in the OpenStack 
universe since Kilo. As a result of this long involvement, I have always had a 
strong interest in helping to shape the direction of OpenStack, and if there is 
one thing people will agree about me, is that I'm never shy about voicing my 
opinion, whether the majority agree with me or not (they usually don't!). I now 
spend most of my time working on Nova and the new Placement service. I also 
spend a good deal of time arguing over obscure HTTP issues with the API Working 
Group, and sometimes blog about them [0].

You'd think that with this long involvement, I'd be happy to see OpenStack 
continue on the course it's been on, and for the most part, you'd be right. 
What we've gotten right is the way we work together, focusing on community over 
corporate interests - that is essential for any project like OpenStack. What we 
really could improve, though, is how we focus our efforts, and how we set 
ourselves up for the future.

The Big Tent change was important for making this feel like an inclusive 
community, and for allowing for some competition among differing approaches. 
Where I think it's been problematic is that while the notion that "we're all 
OpenStack" is wonderful, this egalitarian approach has made it somewhat 
confusing, not only to the outside markets, but to the way we govern ourselves. 
I think that it's important to recognize that OpenStack can be divided into two 
parts: Infrastructure as a Service (IaaS), and everything else. Monty Taylor 
first outlined this split back in 2014 [1], and while there is still some room 
to debate which projects fall into which group, I think it's a more important 
distinction than ever. The "Layer 1" projects have a strong dependency on each 
other, and need to have a common way of doing things. But for all the other 
projects that build on top of this core, that sort of conformity is not 
critical. In fact, it can be a hindrance. So I believe that different technical 
rules should apply to these two groups.

The recent discussions on the approval of Golang and other languages into the 
OpenStack ecosystem [2] highlighted the need for this division. For the core 
IaaS projects, there should be a very, very high bar for using !Python. But for 
the others, I'd prefer to let them make their own choices. If they choose a 
language that is difficult to deploy and maintain, or that doesn't create logs 
like the rest of OpenStack, it's going to wither and die unless the benefits it 
brings is great enough to make that increased burden.

To my mind, this is the only way to make OpenStack better: focus on making the 
IaaS core as rock-solid and dependable as possible, but then open things up for 
experimentation everywhere else. As long as a project follows the Four Opens 
[3], let them make the decisions on the trade-offs. As an API wonk, that's what 
the benefit of consistent APIs offers: the ability of any app to interact, not 
just those written in the same language.

This ties in with my other main concern: the narrowing-but-still-wide 
separation between OpenStack developers and operators. We've made a lot of 
progress over the last few cycles, but we still need to get a lot better. In my 
former life in the construction industry, there were always architects who 
designed very interesting things, but which were a complete pain to build. 
Inevitably this was the result of the architect having little practical 
experience in the field getting their hands dirty building things. Many of the 
comments I've heard from OpenStack operators have a similar aspect to them. I 
know that I have never run a large cloud, so when an operator tells me about an 
issue, I listen. I'd like to see the TC continue to encourage more 
opportunities for OpenStack developers to be able to listen and work with 
OpenStack operators.

So if you're still reading up to this point, perhaps you might want to consider 
voting for me for the TC. But either way, please ask questions of the 
candidates. That's the only way to know that the people you choose share your 
concerns, and that will help to ensure that the TC represents your interests.

[0] https://blog.leafe.com
[1] 
http://superuser.openstack.org/articles/openstack-as-layers-but-also-a-big-tent-but-also-a-bunch-of-cats/
[2] 
https://github.com/openstack/governance/blob/master/reference/new-language-requirements.rst
[3] https://governance.openstack.org/tc/reference/opens.html

-- Ed Leafe







signature.asc
Description: Message

  1   2   3   4   >