Re: [openstack-dev] [all] Naming the T release of OpenStack
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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?
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!
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
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!
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
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
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
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
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
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
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
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
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)
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
On May 10, 2018, at 12:50 AM, Takashi Natsume 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?
On May 3, 2018, at 12:50 PM, Jay Pipes 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
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?
On May 2, 2018, at 2:40 AM, Gilles Dubreuil 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
On Apr 29, 2018, at 1:34 PM, Artom Lifshitz 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
On Apr 18, 2018, at 10:58 AM, Matt Riedemann 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
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
On Mar 29, 2018, at 12:57 PM, Eric Fried 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 ?
On Mar 23, 2018, at 10:16 AM, Matt Riedemann 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?
On Mar 21, 2018, at 11:35 AM, 少合冯 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?
On Mar 21, 2018, at 10:56 AM, 少合冯 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
On Mar 15, 2018, at 10:31 PM, Gilles Dubreuil 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
Just FYI to all the people who don't prioritize moving our code to Python3: > Begin forwarded message: > > From: Terry Reedy > 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
On Mar 5, 2018, at 9:51 PM, Zhipeng Huang 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
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
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
On Feb 15, 2018, at 9:43 AM, Steven Dake (stdake) 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
On Feb 15, 2018, at 2:41 PM, Marcin Juszkiewicz 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
On Feb 12, 2018, at 9:57 AM, Chris Dent 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
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
On Feb 2, 2018, at 2:11 AM, Duncan Thomas 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
On Jan 18, 2018, at 4:07 AM, TommyLike Hu 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
On Jan 22, 2018, at 5:09 PM, Matt Riedemann 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
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
On Jan 16, 2018, at 7:21 PM, Zhenyu Zheng 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
On Dec 14, 2017, at 7:07 AM, Thierry Carrez 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
On Dec 14, 2017, at 3:01 AM, Thomas Goirand 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
On Dec 14, 2017, at 12:55 AM, Clint Byrum 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
On Dec 13, 2017, at 5:44 PM, Clint Byrum 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
On Dec 13, 2017, at 4:38 PM, German Eichberger 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
On Dec 13, 2017, at 4:31 PM, Doug Hellmann 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
On Dec 13, 2017, at 12:13 PM, Tim Bell 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
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
On Dec 7, 2017, at 11:22 AM, Ed Leafe 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
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
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!!
On Nov 2, 2017, at 4:17 AM, Dmitry Tantsur 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
On Oct 26, 2017, at 6:57 PM, Wan-yen Hsu 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
On Oct 26, 2017, at 9:52 AM, Doug Hellmann 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
On Oct 25, 2017, at 10:36 PM, Tony Breeds 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
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?
On Oct 13, 2017, at 2:21 PM, Zane Bitter 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
On Oct 12, 2017, at 8:10 PM, Mohammed Naser 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
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
On Oct 6, 2017, at 8:21 AM, Chris Dent 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
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
On Sep 14, 2017, at 10:30 AM, melanie witt 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
On Sep 5, 2017, at 10:02 AM, Andrey Volkov 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
On Jul 24, 2017, at 5:05 AM, Chris Dent 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
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"
On Jul 14, 2017, at 2:17 PM, Zane Bitter 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"
On Jul 13, 2017, at 10:32 PM, Fei Long Wang 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
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?
On Jul 11, 2017, at 8:18 PM, Matt Riedemann 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
On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin 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
On Jun 15, 2017, at 3:35 PM, Jeremy Stanley 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
On Jun 9, 2017, at 4:35 PM, Jay Pipes 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
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
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
On May 30, 2017, at 9:36 PM, Zhenguo Niu 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
On May 30, 2017, at 9:08 PM, Zhenguo Niu 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
On May 16, 2017, at 3:06 PM, Jeremy Stanley 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
On May 3, 2017, at 2:41 AM, Thierry Carrez 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
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
On Apr 11, 2017, at 9:54 PM, joehuang 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
On Apr 12, 2017, at 11:19 AM, Kendall Nelson 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
On Apr 12, 2017, at 9:44 AM, gordon chung 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
On Apr 11, 2017, at 12:48 PM, Jay Pipes 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
On Apr 10, 2017, at 3:40 PM, Matt Riedemann 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
On Apr 10, 2017, at 4:16 AM, Thierry Carrez 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
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-require
