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

Greetings OpenStack community, Today's meeting was even shorter and sweeter than last week's, as only edleafe was present, due to cdent being on PTO and elmiko being on the road. Prior to the meeting, though, we had decided that the guideline change for raising the minimum microversion was

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 20, 2017, at 8:38 AM, Jay Pipes wrote: > >>> The example I posted used 3 resource providers. 2 compute nodes with no >>> local disk and a shared storage pool. >> Now I’m even more confused. In the straw man example >> (https://review.openstack.org/#/c/471927/ >>

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 20, 2017, at 6:54 AM, Jay Pipes wrote: > >>> It was the "per compute host" that I objected to. >> I guess it would have helped to see an example of the data returned for >> multiple compute nodes. The straw man example was for a single compute node >> with SR-IOV,

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 19, 2017, at 5:27 PM, Jay Pipes wrote: > >> It was from the straw man example. Replacing the $FOO_UUID with UUIDs, and >> then stripping out all whitespace resulted in about 1500 bytes. Your >> example, with whitespace included, is 1600 bytes. > > It was the "per

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 19, 2017, at 1:34 PM, Jay Pipes wrote: > >> OK, thanks for clarifying that. When we discussed returning 1.5K per compute >> host instead of a couple of hundred bytes, there was discussion that paging >> would be necessary. > > Not sure where you're getting the whole

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 19, 2017, at 9:17 AM, Jay Pipes wrote: As Matt pointed out, I mis-wrote when I said “current flow”. I meant “current agreed-to design flow”. So no need to rehash that. >> * Placement returns a number of these data structures as JSON blobs. Due to >> the size of the

[openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

There is a lot going on lately in placement-land, and some of the changes being proposed are complex enough that it is difficult to understand what the final result is supposed to look like. I have documented my understanding of the current way that the placement/scheduler interaction works,

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 12, 2017, at 10:20 AM, Jay Pipes wrote: >> 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,

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

On Jun 8, 2017, at 11:59 AM, Chris Dent wrote: > > The naming issue related to an optional field we want to add to the > microversion discovery document. Some projects wish to be able to signal that > they are intending to raise the minimum microversion at a point in

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

Sorry for the top-post, but it seems that nobody has responded to this, and there are a lot of important questions that need answers. So I’m simply re-posting this so that we don’t get too ahead of ourselves, by planning implementations before we fully understand the problem and the

Re: [openstack-dev] [ironic][nova] Goodbye^W See you later

On Jun 8, 2017, at 7:45 AM, Jim Rollenhagen wrote: > I've been mostly missing for the past six weeks while looking for a new job, > so maybe you've forgotten me already, maybe not. I'm happy to tell you I've > found one that I think is a great opportunity for me. But,

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 7, 2017, at 1:44 PM, Mooney, Sean K > wrote: > [Mooney, Sean K] neutron will need to use nested resource providers to track > Network backend specific consumable resources in the future also. One example > is > is hardware

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 7, 2017, at 1:44 PM, Mooney, Sean K > wrote: > [Mooney, Sean K] neutron will need to use nested resource providers to track > Network backend specific consumable resources in the future also. One example > is > is hardware

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 6, 2017, at 9:56 AM, Chris Dent wrote: > > For clarity and completeness in the discussion some questions for > which we have explicit answers would be useful. Some of these may > appear ignorant or obtuse and are mostly things we've been over > before. The goal is

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 6, 2017, at 4:14 AM, Sylvain Bauza wrote: > > The Plan A option you mention hides the complexity of the > shared/non-shared logic but to the price that it would make scheduling > decisions on those criteries impossible unless you put > filtering/weighting logic into

[openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

[resending to include the operators list] The host_subset_size configuration option was added to the scheduler to help eliminate race conditions when two requests for a similar VM would be processed close together, since the scheduler’s algorithm would select the same host in both cases,

[openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

The host_subset_size configuration option was added to the scheduler to help eliminate race conditions when two requests for a similar VM would be processed close together, since the scheduler’s algorithm would select the same host in both cases, leading to a race and a likely failure to build

Re: [openstack-dev] [tc] Active or passive role with our database layer

On May 23, 2017, at 1:43 PM, Jay Pipes wrote: > [1] Witness the join constructs in Golang in Kubernetes as they work around > etcd not being a relational data store: Maybe it’s just me, but I found that Go code more understandable than some of the SQL we are using in the

[openstack-dev] [nova][scheduler] Discussion on how to do claims

I missed the summit, so I also missed out on some of the decisions that were made. I don’t feel that some of them were ideal, and in talking to the people involved I’ve gotten various degrees of certainty about how settled things were. So I’ve not only pushed a series of patches as POC code [0]

Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On May 15, 2017, at 9:00 PM, Flavio Percoco wrote: > [huge snip] Thank you! We don’t need 50K of repeated text in every response. -- Ed Leafe __ OpenStack Development Mailing List (not for usage

[openstack-dev] [nova] Scheduler meeting canceled for next Monday

Due to most participants being at the Forum this coming week, we will not hold our weekly Scheduler sub team meeting on Monday, May 8. Please join us the following Monday (May 15) in #openstack-meeting-alt at 1400 UTC. -- Ed Leafe

[openstack-dev] [api-wg][all] API-WG Liaison Update request

An important step in the process of creating API guidelines is getting feedback from the projects that will be affected by those guidelines before we approve them. To that end, we have encouraged projects to appoint a liaison, and when a guideline is approved by the WG, these liaisons are added

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

On Apr 10, 2017, at 1:52 PM, Matt Riedemann wrote: > > How will the TC grow a diverse membership if it's not even held, at least > every other week, in a timezone where the other half of the world can attend? +1 --

Re: [openstack-dev] [api]

On Nov 14, 2016, at 3:14 PM, Ed Leafe wrote: > Since we already had ‘new’, I thought that ‘nin’ would be consistent. No > other reason to prefer it, though. s/new/neq Damn you autocorrect! -- Ed Leafe

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

On Oct 3, 2016, at 1:39 PM, Clint Byrum wrote: > > Of course, I read the essays of those who I don't know more carefully, and > I often go searching through my ML archives to see if we've interacted on > threads in the past. Still, I'm very unlikely to rank somebody higher than

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

On Oct 3, 2016, at 12:18 PM, Clay Gerrard wrote: > >> After the nominations close, the election officials will assign each >> candidate a non-identifying label, such as a random number, and those >> officials will be the only ones who know which candidate is associated

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

On Oct 3, 2016, at 12:51 PM, Doug Hellmann wrote: > When I vote, I consider the positions a candidate takes, the ideas > they propose, and -- equally importantly -- their track record of > actually getting things done. Hiding the candidate's identity makes > it impossible

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

So the period of self-nominations for the Technical Committee seats has ended, and the voting has begun. I've been a very close observer of this process for several cycles, and I have some ideas I'd like to share. Full disclosure: I am a current candidate for the TC, and have been a candidate

Re: [openstack-dev] [tc] open question to the candidates

On Oct 3, 2016, at 10:30 AM, gordon chung wrote: > the TC has historically been a reactive council that lets others ask for > change and acts as the final approver. do you believe the TC should be a > proactive committee that initiates change and if yes, to what scope? > more

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

On Sep 8, 2016, at 8:13 AM, Chris Dent wrote: > The writing is starting from a detailed proposal which, as txx said in > his response to me above, presents itself as a document that is "meant > to document *existing* principles that we operate under but never > documented

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

On Aug 27, 2016, at 12:18 PM, HU, BIN wrote: >> From telco perspective, those are the areas that allow innovation, and >> provide telco customers with new types of services. > > We need innovation, starting from not limiting ourselves from bringing new > idea and new use

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

On Aug 4, 2016, at 8:18 AM, Andrew Laski wrote: > This gets to the point I'm trying to make. We don't guarantee old > behavior in all cases at which point users can no longer rely on > microversions to signal non breaking changes. And where we do guarantee > old behavior

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

Sorry for the late email, but I was swamped last week after getting back from the mid-cycle. The next meeting of the Nova Scheduler subteam will be Monday, August 1, at 1400 UTC [0], in #openstack-meeting-alt I've updated the agenda [1] with the main items; if you have other issues to discuss,

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

On Jul 13, 2016, at 9:38 PM, Cheng, Yingxin wrote: >>Thinking about that a bit, it would seem that a host aggregate could also >> be represented as a namespace:name tag. That makes sense, since the fact >> that a host belongs to a particular aggregate is a

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

On Jul 7, 2016, at 8:33 PM, Joshua Harlow wrote: > > That's sad, how can we fix the fact that users/deployments have gone off into > their own silos and may be running their own forks; what went wrong (besides > some of the obvious stuff that I think I know about, that

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

On Jun 29, 2016, at 10:05 PM, Matt Riedemann wrote: > >>> 2. The updated_at field is also empty, should we sync the updated_at >>> time to the created_at time when we create the action and also update >>> it whenever the action status changed, e.g finished. >> >>

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

On Jun 18, 2016, at 9:03 AM, Clint Byrum wrote: > Whatever API version is used behind the compute API is none of the user's > business. Actually, yeah, it is. If I write an app or a tool that expects to send information in a certain format, and receive responses in a certain

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

On Jun 14, 2016, at 5:50 PM, Matthew Treinish wrote: > But, if we add another possible state on the defcore side like conditional > pass, > warning, yellow, etc. (the name doesn't matter) which is used to indicate that > things on product X could only pass when strict

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

On May 9, 2016, at 1:58 PM, Hayes, Graham wrote: > This is not a "Go seems cool - lets go try that" decision from us - we > know we have a performance problem with one of our components, and we > have come to the conclusion that Go (or something like it) is the > solution.

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

The next meeting for the Scheduler sub-team will be on Monday, May 9 at 1400 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160509T14) The agenda for the meeting is here; please add any items that you wish to discuss:

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

On May 4, 2016, at 3:53 PM, Jay Pipes wrote: > My position is that if it's an HTTP API (as opposed to something like a > sqlalchemy-migrate sync command) then it belongs in a client that speaks the > OpenStack HTTP APIs. That is OSC as far as I can tell. I don't see a >

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

On May 3, 2016, at 7:05 PM, Mark Doffman wrote: > This thread has been a depressing read. > > I understand that the content is supposed to be distributed databases but for > me it has become an inquisition of cellsV2. Thanks for bringing this up, and I feel a lot

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

On May 3, 2016, at 6:45 AM, Miles Gould wrote: >> This DB could be an RDBMS or Cassandra, depending on the deployer's >> preferences > AFAICT this would mean introducing and maintaining a layer that abstracts > over RDBMSes and Cassandra. That's a big abstraction, over two

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

On May 2, 2016, at 10:51 AM, Mike Bayer wrote: >> Concretely, we think that there are three possible approaches: >> 1) We can use the SQLAlchemy API as the common denominator between a >> relational and non-relational implementation of the db.api component. These >> two

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

On Apr 28, 2016, at 5:35 PM, Clint Byrum wrote: > - Vitess [2] is a proven technology that serves _every_ request to > Youtube, and provides a familiar SQL interface with sharding built > in. Shard by project ID and you can just use regular index semantics. > Or if that's

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

On Apr 28, 2016, at 1:09 PM, Jay Pipes wrote: > nova list as an admin (or any user frankly) should be a proxy call to Project > Searchlight and elasticsearch. > > elasticsearch is a great interface for this kind of operation. We should use > it. Oh, that’s great! A

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

On Apr 24, 2016, at 3:28 PM, Robert Collins wrote: > For instance, the things I think are essential for a distributed > database based datastore: > - good single-machine developer story. Must not need a physical > cluster to hack on OpenStack > - deal gracefully with

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

On Apr 24, 2016, at 3:28 PM, Robert Collins wrote: > Heh, glad you said it! :) -- Ed Leafe __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

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

On Apr 24, 2016, at 6:41 AM, Michael Bayer wrote: > I'm only seeking to counter what appears to be the premise of your blog post, > which is that distributed and SQL are mutually exclusive. When you say, > "why don't we just query the database?" You can make distributed

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: > BTW, note to Ed Leafe... unless your distributed data store supports > transactional semantics, you can't use a distributed data store for these > types of solutions. Instead, you will need to

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

On Apr 23, 2016, at 10:10 AM, Thierry Carrez wrote: >> I think replacing nova's persistent storage layer with a distributed >> database would have a great effect - but I do not think it would have >> anything to do with the database itself. It would come from the act that

[openstack-dev] [nova-scheduler] Scheduler team meeting Monday, 2016.04.18 1400 UTC

Sorry for the late note, but busy weekend, etc. The next Nova Scheduler meeting will be tomorrow (Monday) at 1400 UTC in #openstack-meeting-alt http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160418T14 The agenda is posted here:

Re: [openstack-dev] [nova] Newton midcycle planning

On Apr 12, 2016, at 6:07 PM, Bhandaru, Malini K wrote: > Intel would be pleased to host the Nova midcycle meetup either at San > Antonio, Texas or Hillsboro, Oregon during R-15 (June 20-24) or R-11 (July > 18-22) as preferred by the Nova community. In July?

[openstack-dev] [nova][scheduler] Next Meeting: Monday, April 4 @ 1400UTC

The next meeting for the Nova Scheduler sub-team is scheduled for Monday, April 4 at 1400 UTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160404T14 The agenda is at https://wiki.openstack.org/wiki/Meetings/NovaScheduler - feel free to add items that need to be discussed to

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

Greetings! I am announcing my candidacy for the OpenStack Technical Committee. As a long-time developer, I have been part of projects that have succeeded and others that have not; in either event, I always learned something to apply to the next endeavor. I would like to use that experience to

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

On Feb 16, 2016, at 1:30 PM, Doug Hellmann wrote: > So I think the project team is doing everything we've asked. We > changed our policies around new projects to emphasize the social > aspects of projects, and community interactions. Telling a bunch > of folks that they