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
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/
>>
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,
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
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
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
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,
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,
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
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
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,
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
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
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
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
[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,
[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,
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
On May 23, 2017, at 3:15 PM, melanie witt wrote:
>
> Removing the small VM driver from Nova would allow people to keep using what
> they know (Nova API) but would keep a lot of cruft with it. So I would tend
> to favor a new porcelain API.
This.
-- Ed Leafe
On May 23, 2017, at 1:27 PM, James Penick wrote:
> Perhaps this is a place where the TC and Foundation should step in and
> foster the existence of a porcelain API. Either by constructing something
> new, or by growing Nova into that thing.
Oh please, not Nova. The last
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
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]
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
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
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
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
--
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
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
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
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
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
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
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
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
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
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,
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
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
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.
>>
>>
On Jun 22, 2016, at 10:40 AM, Ed Leafe wrote:
>
>> https://wiki.openstack.org/wiki/Release_Naming/P_Proposals
>
> Have we gotten clearance on all of these? Specifically, ‘podunk’ has some
> negative connotations:
>
> http://www.urbandictionary.com/define.php?term=podunk
Never
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
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
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.
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:
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
>
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
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
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
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
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
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
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:
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
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
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
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:
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?
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
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
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
60 matches
Mail list logo