Re: [openstack-dev] [relmgt] PTL non-candidacy

, and thank you for your wisdom in recognizing this. You've done us all so much good with your Release Management work to date, and I'm glad that you'll still be involved. -- Ed Leafe signature.asc Description: Message signed with OpenPG

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

ht replace. That will be a difficult task indeed, but I believe that I have the long-term experience to help guide OpenStack as it continues to grow and thrive in the future. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderb

Re: [openstack-dev] [all][elections] PTL nomination period is now over

he election repo at any time during the cycle up to the firm deadline? This might also encourage candidates not to wait until the last minute. -- Ed Leafe signature.asc Description: Message signed with OpenPGP using GPGMail

Re: [openstack-dev] [all] Time to increase our IRC Meetings infrastructure?

On Nov 24, 2015, at 4:35 AM, Thierry Carrez <thie...@openstack.org> wrote: > I'd rather standardize and rename -alt to -2 (i.e. redirect -alt to -2 > on IRC, and bulk-change all meetings YAML from -alt to -2). +1. 'alt' is confusing. -- Ed Leafe signature.asc Description: Me

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

trong an objection in including Poppy. -- 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] Languages vs. Scope of "OpenStack"

evolution. Evolution is also not without pain; without such stress evolution simply doesn’t happen. The discussion is about one such pain point, and how to best address it so as to eliminate the pain with the minimal amount of impact on the community. --

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

re would be little or no controversy with this approach, as it’s much less disruptive to the overall community. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@l

[openstack-dev] [nova][scheduler] Next scheduler subteam meeting

before the meeting. And since we are starting to plan for the midcycle, please add any topics you feel would be appropriate to that section of the agenda. -- Ed Leafe __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Magnum] The Magnum Midcycle

On Jun 14, 2016, at 3:37 PM, Anita Kuno <ante...@anteaya.info> wrote: > > What other projects would make sense for you to host mid-cycles for > should the opportunity arise? I can keep my ears open. Nova! Nova! Nova! -- Ed Leafe (really wants

[openstack-dev] [nova][scheduler] Next Scheduler Sub-team Meeting: Monday June 20 at @1400 UTC

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

Re: [openstack-dev] Version header for OpenStack microversion support

ven made it possible to accept both header formats [0] until things can be migrated to the recommended format. [0] https://review.openstack.org/#/c/300077/ -- Ed Leafe __ OpenStack Development Mailing List (not for

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

rce software. I just don't think it's > OpenStack. Agreed. I don't think that everything that may be useful to consumers of OpenStack has to be part of OpenStack, either. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Co

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

gt; From a QA perspective in gate, if we have to rely on a commercial >> solution > (even if donated) to test it, then that's bad. Wasn't that the exact argument regarding needing to be able to boot a Linux image? We can't reasonably test it without getting into payment/licensing is

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

ho were using 'tenant' in their existing code, there was much discussion over which made the most sense. And since RAX pretty much footed the entire bill for those early days, guess which prevailed. :) - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https:/

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

a big > limitation on our possible solutions to a fair few problems (notably > scheduling). Some chatter is necessary to assure system health, but yeah, this should be considered a bug. I'm sure that if a RabbitMQ expert were able to observe this, the response would be &

Re: [openstack-dev] [all] A proposal to separate the design summit

le together to discuss an issue, and then moving them again to form a different group. There also weren't many separate teams then, so it was pretty much everyone in a few rooms. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Commen

Re: [openstack-dev] [all] A proposal to separate the design summit

grown to be so huge, the flight savings have been overwhelmed by the hotel costs in most cases. Making the events smaller, like the midcycles, can allow us to hold them in much smaller venues with much less expensive hotels. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Co

Re: [openstack-dev] [all] A proposal to separate the design summit

t the people leading the commitment to OpenStack (*cough*IBM*cough*). In other words, travel to events is not counted as part of the business support for OpenStack. So the issue doesn't only affect small companies with tiny budgets. -- -- Ed Leafe signature.asc Description: OpenPGP digital signature __

Re: [openstack-dev] [all] A proposal to separate the design summit

accepted. If you now have a separate summit/meeting for the developers away from the big splashy business event, I'm wondering if we might make it harder for many developers to get funded for this travel. That said, I'm 100% behind the idea. I go to the summits to discuss code, not to watch PowerPoint sl

Re: [openstack-dev] [all] A proposal to separate the design summit

; I gratefully accept this challenge. I work for such a company, too, and I suspect that the layers of management that need such convincing are much further removed in my case. You and I, though, might have a little more clout than, let's say, someone just starting out in OpenStack. - -- - -- Ed Leafe --

Re: [openstack-dev] [all] A proposal to separate the design summit

e may > still have sprints to get specific things completed, but as recent > experiments have shown, holding them virtually is an option. I had to miss the recent Nova midcycle, and I felt like I was completely out of the loop afterwards. So anything that can maximize the ability to part

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

t also having to get everything that was also introduced in 2.X-1 and before. The benefit, of course, is that the user will have changed something explicitly before getting the new behavior, and at least has a chance of figuring it out. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Ver

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

ory. That was resisted by several large operators, due to overhead. This proposal will have to store that and more in memory. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.

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

ources on the same hardware, it makes sense. But yeah, for Keystone (and most other services in OpenStack), project is clearer, IMO. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigma

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

because we can't make everyone happy. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJWx2GtAAoJEKMgtcocwZqL61wQALYd9VMWXtNiG31Y2G8p4sPE Ya9jb4

Re: [openstack-dev] [nova] patches that improve code quality

erging code that might conflict with those changes. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJW4ZwoAAoJEKMgtcocwZqL8MwQAJKugI/FOFWCYptWnQbG

Re: [openstack-dev] [oslo] Removing Nova specifics from oslo.log

de to find out what they did. I could see a similar effort for oslo.log (and maybe other oslo projects), and I would be happy to help out. -- -- Ed Leafe signature.asc Description: OpenPGP digital signature __ OpenStack Devel

Re: [openstack-dev] [neutron] [API]Make API errors conform to the common error message without microversion

ents would be appreciated. You should probably follow the guidelines set up by the API Working Group: https://specs.openstack.org/openstack/api-wg/guidelines/headers.html In particular, having a header that does just one thing goes against the spirit of avoiding header proliferation. -- -- Ed Leafe

[openstack-dev] [nova][scheduler] Nova Scheduler sub-team meeting 2016-03-28

topics you would like to discuss. -- -- Ed Leafe signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

people not to use something unless you can point them to a better way to accomplish what they need to do. -- -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@list

[openstack-dev] [nova] Distributed Database

, drive) to Austin, and feel free to pull me aside to explain just how wrong I am. ;-) -- -- Ed Leafe signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] More on the topic of DELIMITER, the Quota Management Library proposal

On Apr 23, 2016, at 3:10 PM, Jay Pipes wrote: > > Looking forward to arriving in Austin so that I can buy you a beer, Amrith, > and have a high-bandwidth conversation about how you're wrong. :P Beer is a great addition to any conversation! -- Ed

Re: [openstack-dev] [nova] Distributed Database

On Apr 23, 2016, at 10:08 PM, Jay Pipes wrote: > > think it's amusing that Redis was Nova's original "database". :) > > I "fondly" remember having to work with the original Redis store interface > for complex data. Oh the fun that was had. I think my first commits to

Re: [openstack-dev] [nova] Distributed Database

On Apr 23, 2016, at 11:33 PM, Mike Bayer wrote: > > Facebook and LinkedIn have built distributed database systems based on MySQL > at profoundly massive scales. Openstack's problem I'm going to guess isn't as > hard as that. That's always the problem with citing

[openstack-dev] [nova][scheduler] Next Scheduler sub-team meeting

would like to discuss. -- 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

[openstack-dev] [nova][scheduler] Next meeting: Monday May 16 at 1400 UTC

add them to the agenda page. https://wiki.openstack.org/wiki/Meetings/NovaScheduler See you then! -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

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

using ctypes. > > NO, we should paint it yellow! Not even close to bikeshedding. C extensions live all throughout the Python world, and are not the equivalent of a completely new language to the ecosystem. And the point was to simply speed up

Re: [openstack-dev] [nova] Question on removal of 'arbitrary' pluggable interfaces

ecated_for_removal=True Also note that while the option isn't deprecated, some allowable formats are being deprecated; those also have a note to that effect, as in: https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L258-L260 -- -- Ed Leafe signature.asc Description: OpenPGP

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

of effort. You can always achieve more working together, though it will never happen as fast as when you go it alone. It’s a trade-off: the needs of the vendor vs. the health of the community. -- Ed Leafe __ OpenStack D

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

On Jul 27, 2016, at 12:10 PM, Chris Friesen <chris.frie...@windriver.com> wrote: > Maybe it boils down to the definition of "gratuitous" competition. Precisely, which is why we have humans and not computer algorithms to decide these t

Re: [openstack-dev] [nova] [placement] unresolved topics in resource providers/placement api

stpone supporting that until the placement API was available. I think that providing a subset of all resource providers to the placement API to limit the potential results is an important addition, especially with the eventual thought of having this be a generic placement API

Re: [openstack-dev] [ironic][nova] Indivisible Resource Providers

with the rest of the resource provider design, as having many, many classes all of which represent identical hardware seems backwards. -- Ed Leafe __ OpenStack Development Mailing List (not for usage qu

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

stems in production, > and rely on that api being consistent. > > I'm positive I'm not the only operator doing this either. This sounds like a > consumable api to me. I don’t think that an API has to be RESTful to be considered an interface for

Re: [openstack-dev] [Nova] Does this api modification need Microversion?

e patch yet, but in general correcting an error on the server doesn’t require a microversion, unless the response to the user would change. From your description it doesn’t sound like that is the case. -- Ed Leafe __ Op

Re: [openstack-dev] [tc] persistently single-vendor projects

heir activities. They have > the right intent but how to measure intent objectively? That would be my > major concern. This is exactly the sort of reason why an automatic expulsion is not being proposed, but rather a review by

Re: [openstack-dev] [tc] persistently single-vendor projects

cts that are largely single-vendor are approved for the big tent with the understanding that they need to diversify. I believe that it is these types of projects that we are discussing. -- Ed Leafe __ OpenStack Development Mai

Re: [openstack-dev] [nova] os-capabilities library created

dard way of representing *qualitative* aspects of resources. So while we are not actively trying to make this a placement engine for all OpenStack services yet, the goal is to not be Nova-specific, so that once we have this up and running, we can offer it as a general placement service for any o

Re: [openstack-dev] [nova] os-capabilities library created

e not simple tags, but nested data structures in string form. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [nova] os-capabilities library created

m meeting Mondays at 1400 UTC in @openstack-meeting-alt, where we discuss our current efforts. If you have a specific question or topic to bring up, add it to the meeting agenda at https://wiki.openstack.org/wiki/Meetings/NovaScheduler. -- Ed Leafe _

[openstack-dev] [nova][scheduler] Next Scheduler Subteam meeting

to discuss, please add them to the agenda before the meeting. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

sense, since the fact that a host belongs to a particular aggregate is a qualitative aspect of that host. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ..

Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

ent about attributes for tags. Yes, a thousand times yes to attributes! There can be several standards, such as ‘compute’ or ‘networking’ that we use for some basic cross-cloud compatibility, but making them flexible is a must for adoption. I can update the qualitative request spec to add Resource

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

(Barbican and Zaqar are the obvious ones here) have matured to the point where it makes sense to standardize on them. They are mature, and no other projects have come along to challenge their designs. At some point, it makes se

Re: [openstack-dev] FPGA as a dynamic nested resources

r doesn't need to know about > whole FPGAs. That was where we left the discussion in Austin, so that was my assumption. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] FPGA as a dynamic nested resources

elerators, you now have 8 consumable resources. The fact that they came from a particular FPGA unit doesn’t seem relevant from a scheduling perspective. -- Ed Leafe __ OpenStack Development Mailing List

Re: [openstack-dev] FPGA as a dynamic nested resources

va should be in the business of FPGA management, but once we get the basic functionality supporting FPGA working well, seeing what would be needed to add it would be much easier, and we could make a clearer determination as to whether this is fe

[openstack-dev] [nova][scheduler] Capability Modeling - Newton Mid-cycle Status

] https://review.openstack.org/#/c/286520 [3] https://review.openstack.org/#/c/309762 -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

vor of updating that statement. -- 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/m

[openstack-dev] [nova][scheduler] Next meeting: Monday, July 11 at 1400 UTC

If you have anything specific to discuss, please update the agenda as soon as possible so that others may review before the meeting. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe

Re: [openstack-dev] [Nova] Some thoughts on API microversions

to use *all* of the older microversions. So in this case, we are creating a new microversion that simply signals “nova-network is no longer here”. It doesn’t act like the original intent on microversions (preservation of older APIs). -- Ed Leafe _

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

tory thing. Oh, and think of the person coming in new to the placement engine, and having to explain what an infinite inventory is. Imagine their face. -- Ed Leafe __ OpenStack Development Mailing List (no

Re: [openstack-dev] [nova] [placement] *future* topics in resource providers/placement api

we could change the ‘get_all_hosts’ to ‘get_all_hosts_unless_I_already_have_some_hosts”. :) -- 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] [nova][scheduler] No meeting this Monday, July 4

Due to the US Independence Day holiday, we will be skipping the Nova Scheduler subteam meeting on this upcoming Monday, July 4. The next meeting will be July 11 at 1400 UTC [0]. [0] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160711T14 -- Ed Leafe

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

On Feb 2, 2017, at 10:16 AM, Matthew Treinish <mtrein...@kortar.org> wrote: > <oops, forgot to finish my though> If that was intentional, it is the funniest thing I’ve read today. :) -- Ed Leafe _

Re: [openstack-dev] [all][api] POST /api-wg/news

propose a change to the wording for that, but dropping the guideline completely would be an overreaction, IMO. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-r

Re: [openstack-dev] [watcher] Watcher release v1.0.0

On Feb 3, 2017, at 4:27 AM, Antoine Cabot <antoinecabo...@gmail.com> wrote: > I'm very proud to announce today the availability of Watcher in version 1.0.0. Congratulations! -- Ed Leafe __ OpenStack De

Re: [openstack-dev] [nova] Latest and greatest on trying to get n-sch to require placement

t, you must also ensure you update the configuration, to stop using any deprecated features or options, and perform any required work to transition to alternative features.” So yes, "updating your configuration” is an expected ac

[openstack-dev] [api-wg][ptg] Room for API-WG in Atlanta PTG

Just to let everyone know - we’ve been given our own room for the PTG: Georgia 5: Level 1 on Monday and Tuesday. So we won’t have to be crowding out the Architecture WG. :) -- Ed Leafe __ OpenStack Development Mailing

Re: [openstack-dev] [api] API WG PTG planning

ssion is one of the ones we are planning on: https://etherpad.openstack.org/p/ptg-architecture-workgroup -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-

[openstack-dev] [nova] placement/resource providers update 11

planning for the discussions at the PTG around what our goals for Pike will be. I'm sure that there will a summary of those discussions in one of these emails after the PTG. -- Ed Leafe signature.asc Description: Message signed with OpenPGP

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

ting > projects. Basically, the market would decide on the "optimal" > solution. It's a hard message to hear, but that seems to be what > is happening. This. We got much better at adding new things to OpenStack. We need to get better at lett

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

On Feb 16, 2017, at 10:12 AM, Ed Leafe <e...@leafe.com> wrote: > We got much better at adding new things to OpenStack. We need to get better > at letting go of old things. On re-reading that, it doesn’t sound like what I intended. By “old” I mean things that no longer have e

[openstack-dev] Subject: [all][api] POST /api-wg/news

/API-WG#Agenda Past Meeting Records http://eavesdrop.openstack.org/meetings/api_wg/ Open Bugs https://bugs.launchpad.net/openstack-api-wg -- Ed Leafe __ OpenStack Development Mailing List (not for usage qu

[openstack-dev] [nova][scheduler] Next Nova Scheduler Subteam Meeting

to discuss, please add them to the agenda before the meeting. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [all][massively distributed][architecture] Coordination between actions/WGs

rchitecture, then it isn’t part of OpenStack’s mission. The ‘size’ qualifier relates to everything from massive clouds like CERN and Walmart down to small private clouds. It doesn’t mean ‘any sort of computing platform’; the focus is clear tha

Re: [openstack-dev] [nova] Next steps for resource providers work

completely altered. > * If the latter, alter it. I took Jay’s stuff in 363209 and added back the logic to delete existing allocations. The tests are all passing for me locally, so now we just have to verify that this is indeed the behavior

Re: [openstack-dev] [all][python3] use of six.iteritems()

On Sep 13, 2016, at 10:42 AM, Terry Wilson <twil...@redhat.com> wrote: > All performance matters. All > memory consumption matters. Being wasteful over a purely aesthetic few > extra characters of code is silly. import thi

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

eved, and which is, > in my opinion, not desirable at this stage. Though the two terms looks and sound somewhat similar, “project” and “product” could not be more dissimilar. https://www.linux.com/blog/why-your-open-so

[openstack-dev] [nova][scheduler] Next Scheduler subteam meeting Monday 1400 UTC

://etherpad.openstack.org/p/placement-next Add anything else to the agenda at https://wiki.openstack.org/wiki/Meetings/NovaScheduler -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack

[openstack-dev] TC Candidacy

://www.openstack.org/community/members/profile/280 Freenode: edleafe Website: https://blog.leafe.com Twitter: @edleafe [0] https://en.wiktionary.org/wiki/moon_shot (definition 3) -- Ed Leafe __ OpenStack Development Mailing

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

. So of course this seems a bit self-serving, especially to an outsider who might not know me very well. But I’m sure that Thierry and Doug and others, who have known me for many years, understand my intent: to keep improving OpenStack. -- Ed Leafe __

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

your job, and let those who are elected do the actual work. If the conversations aren’t happening when the people who are voting are most likely to be paying attention, then it’s just a small group talking amongst themselves. And those elected may not represent the v

[openstack-dev] [nova][scheduler] Next Scheduler subteam meeting

items you’d like to discuss to the agenda before the meeting. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

[openstack-dev] [nova][scheduler] Next scheduler subteam meeting

would like to discuss to the agenda. -- 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

[openstack-dev] [nova][scheduler] Next Scheduler sub-team meeting

topics. If you have some ideas, please add them to the agenda at https://wiki.openstack.org/wiki/Meetings/NovaScheduler -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev

Re: [openstack-dev] [Nova] Reconciling flavors and block device mappings

’t think there’s any argument there), then we should treat that part of the request as being as fundamental as a flavor. We need to make the scheduler smarter so that it doesn’t rely on flavor as being the only source of truth. The first step to improving Nova is admitting we have a prob

[openstack-dev] [nova][scheduler] Next Scheduler subteam meeting

you’d like to discuss to the agenda before the meeting. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [all][elections] Results of the TC Election

e sense to have a brief period between > nomination deadline, and poll creation, maybe 1 week, to spark this > debate and get the community engaged with the candidates. This goes for > all of the elections. Exactly. Most people vote when they get their email ballot, s

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

tion. So yes, of course we’re going to drive off those who want to work with the coolest and latest stuff. This isn’t “exciting” work in that sense of the word. -- Ed Leafe __ OpenStack Development Mailing List (not for usa

[openstack-dev] [nova][scheduler] Next Scheduler subteam meeting

to have those discussions in person at the summit. But if people are interested... As always, the agenda is here: https://wiki.openstack.org/wiki/Meetings/NovaScheduler Please add any items you’d like to discuss to the agenda before the meeting. -- Ed Leafe

Re: [openstack-dev] [nova][scheduler] ResourceProvider design issues

> On Oct 17, 2016, at 8:45 PM, Jay Pipes <jaypi...@gmail.com> wrote: > > On 10/17/2016 11:14 PM, Ed Leafe wrote: >> Now that we’re starting to model some more complex resources, it seems that >> some of the original design decisions may have been mistaken. One

Re: [openstack-dev] [api] [nova] microversion edge case query

hod is supported. For microversions after that, 404 is the correct response. For all other methods, the latest version should not have a maximum specified. -- Ed Leafe __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [api]

recommend. Personally, I prefer ‘nin’, but I’ll defer to others on that. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe ht

Re: [openstack-dev] [api]

better than nin. It is on the agenda for the API working group’s meeting tomorrow (Thursday) at 1600 UTC in #openstack-meeting-3 (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20161117T16) Please join the meeting tomorrow if you are abl

[openstack-dev] [nova][scheduler] Next Scheduler subteam meeting

items you’d like to discuss to the agenda before the meeting. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http

Re: [openstack-dev] [api]

on to prefer it, though. > That said, what about something like > > state=!in:x,y,z > > This just makes me nervous that we're beginning to define our own query > language. Ugh - let’s not do that! -- Ed Leafe __

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

swer/clarify process you mention can happen. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.op

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

ch unscientific polling at recent summits. It was the answers I got to these questions that made me start thinking about how to improve the process. -- Ed Leafe __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

are available as soon as the poll begins. I think that this is a great idea, and would be willing to help in the effort to make that happen again. -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Uns

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

pen it up a month before the election, and close it a week before. Or open it for two days, and close it a week before. I don’t understand why, other than procrastination, we need such a long period. If you’re serious about serving, throw you hat into

<    1   2   3   4   >