Sean Dague said on Mon, Sep 08, 2014 at 09:22:56AM -0400:
> > On 09/08/2014 05:17 AM, Steven Hardy wrote:
> >> I think this may be a sensible move, but only if it's used primarily to
> >> land the less complex/risky patches more quickly.
>
> 2 +2 has been part of OpenStack culture for a long time,
Gregory Haynes said on Tue, Sep 09, 2014 at 06:32:38PM +:
> I have been working on a meta-review of StevenK's reviews and I would
> like to propose him as a new member of our core team.
+1 from me!
Alexis
--
Nova Engineer, HP Cloud. AKA lealexis, lxsli.
___
For your amusement,
https://github.com/lxsli/heat-viz
This produces HTML which shows which StructuredDeployments (boxes)
depends_on each other (bold arrows). It also shows the
StructuredDeployments which StructuredConfigs (ovals) feed into (normal
arrows).
Both CFN + HOT format files should
Liuji (Jeremy) said on Mon, Mar 03, 2014 at 08:06:57AM +:
> Test scenario:
> 1)There are two compute nodes in the environment named A and B. A has two
> NICs of vendor_id='8086' and product_id='105e', B has two NICs of
> vendor_id='8086' and product_id='10c9'.
> 2)I configured "pci_alias={"ve
Hiya,
I'm going to step away from TripleO for a while to refocus on Nova. No
reflection on TripleO, this is to align with my local team. It's been a
pleasure working with all of you, I hope I've had some kind of positive
impact and I'm sure we'll still bump into one another now and then.
Alexis
Matthew Gilliard said on Mon, Nov 24, 2014 at 02:50:08PM +:
> 1/ assertFalse() vs assertEqual(x, False) - these are semantically
> different because of python's notion of truthiness, so I don't think
> we ought to make this a rule.
> 2/ expected/actual - I don't see any reason not to try to imp
Dan Prince said on Thu, Dec 04, 2014 at 08:09:56AM -0500:
> > face of backwards-compatibility, but do we want to bite the bullet and
> > remove nova-bm support?
+1, FWIW.
Alexis
--
Nova Engineer, HP Cloud. AKA lealexis, lxsli.
___
OpenStack-dev mail
Clint Byrum said on Wed, Jan 14, 2015 at 10:14:45AM -0800:
> holidays. However, I believe James has demonstrated superb review skills
> and a commitment to the project that shows broad awareness of the
> project.
Big +1. Thanks for taking the time to meta-review, Clint.
Alexis
--
Nova Engineer,
We're seeing the spread of various *-specs projects now, which is great
to see. Some of these (nova, neutron and tripleo) include a Python unit
test (tests/test_titles.py) to check the specs follow the template. The
test has been copy-pasted between projects and it's diverging already.
Nova has a c
Sean Dague said on Fri, May 09, 2014 at 08:20:42AM -0400:
> Based on some of my blog posts on gerrit queries, I've built and gotten
> integrated a custom inbox zero dashboard which is per project in gerrit.
Hi Sean,
I've been looking for something like this! Very nice.
Only one problem - if all
Yuriy Taraday said on Tue, May 20, 2014 at 01:37:29PM +0400:
> On Mon, May 19, 2014 at 8:38 PM, Alexis Lee wrote:
> > Potentially the TITLES structure could
> > be read from a per-project YAML file and the test itself could be drawn
> > from some common area?
>
> I
Sean Dague said on Thu, Mar 06, 2014 at 01:05:15PM -0500:
> The results of this have been that design review today is typically not
> happening on Blueprint approval, but is instead happening once the code
> shows up in the code review. So -1s and -2s on code review are a mix of
> design and code r
Roman Podoliaka said on Mon, Mar 10, 2014 at 03:04:06PM -0700:
> So we have a homework to do: find out what for projects use
> soft-deletes. I assume that soft-deletes are only used internally and
> aren't exposed to API users, but let's check that. At the same time
> all new projects should avoid
Steve Baker said on Wed, Apr 09, 2014 at 10:56:14AM +1200:
> On 09/04/14 10:09, Robert Collins wrote:
> > https://etherpad.openstack.org/p/tripleo-config-passthrough
Blast, replied to the earlier thread before I saw this one. That'll
teach me. I've also appended my competing solution, what do you
Robert Collins said on Wed, Apr 09, 2014 at 01:58:59AM +1200:
> I like this - something like
>
> nova:
> config:
> - section: default
> values:
> - option: 'compute_manager'
> value: 'ironic.nova.compute.manager.ClusterComputeManager'
> - section: cells
> va
Clint Byrum said on Wed, Apr 09, 2014 at 12:05:35PM -0700:
> Excerpts from Duncan Thomas's message of 2014-04-09 11:11:06 -0700:
> > I think this is dangerous thinking - the config you want depends so
> > hugely on your intended workload and available hardware that trying
> > any strong view of wha
Clint Byrum said on Wed, Apr 09, 2014 at 01:33:18PM -0700:
> This assumes that we don't want system integrators to contribute to
> TripleO, which is the opposite of how things are. We absolutely do,
> and in fact, that is part of the point of having a program around
> OpenStack deployment. Let's ge
Miller, Mark M (EB SW Cloud - R&D - Corvallis) said on Wed, Apr 09, 2014 at
10:30:26PM +:
> Does anyone have a flowchart of the cloud build/configure process
> including interactions between the various components/stages of
> TripleO and Heat?
Not to my (very limited) knowledge. If you read t
Clint Byrum said on Thu, Apr 10, 2014 at 09:45:17AM -0700:
> > Now you've described it, you're right, I'm not interested in TripleO or
> > TripleO milestones. I am interested in using os-*-config, Heat and
> > tripleo-image-elements to produce pure OpenStack deployments from 3 to
> > 3000 nodes, fo
Zane Bitter said on Fri, Nov 07, 2014 at 12:35:09AM +0100:
> Crazy thought: why not just implement conditionals? We had a
> proto-spec for them started at one point...
I didn't know that was on the table :)
How about we support YAQL expressions? https://github.com/ativelkov/yaql
Plus some HOFs (h
Alexis Lee said on Mon, Nov 10, 2014 at 05:34:13PM +:
> How about we support YAQL expressions? https://github.com/ativelkov/yaql
> Plus some HOFs (higher-order functions) like cond, map, filter, foldleft
> etc?
We could also use YAQL to provide the HOFs.
> Here's first_nonnu
Zane Bitter said on Tue, Nov 11, 2014 at 04:06:17PM -0500:
> FWIW literally everyone that Clint has pitched the JS
> idea to thought it was crazy ;)
+1
> YAQL ... looks like line noise to me
YAML representing function call stacks (an AST) looks pretty bad to me
:)
The YAQL doc is not great at t
Tomas Sedovic said on Thu, Jul 10, 2014 at 02:26:06PM +0200:
> On 09/07/14 17:52, Clint Byrum wrote:
> +1 for both. However, some of the reviews show what I think is a
> worrying trend in TripleO core. Specifically, nitpicking and tendency to
> bikeshed.
Hi Tomas, thanks for your +1 and thoughts.
Jay S. Bryant said on Wed, Jul 09, 2014 at 10:28:00PM -0500:
> > single quote: LOG.info("The ID '%s' is not invalid." % (resource.id))
> +1 This isn't one I have been policing a lot in my reviews, but think
> this is a good practice.
+1 from me.
> > LOG.info("This path is invalid: %s" % (obj.pat
Robert Collins said on Wed, Jul 16, 2014 at 09:13:52AM +1200:
> Alexis, Jon - core status means a commitment to three reviews a work
> day (on average), keeping track of changing policies and our various
> specs and initiatives, and obviously being excellent to us all :).
Hello,
Thank you all for
Dugger, Donald D said on Tue, Jul 15, 2014 at 09:15:06PM +:
> I `really` dislike paging through 10 screens of an email to discover
> the single comment buried somewhere near the end.
https://wiki.openstack.org/wiki/MailingListEtiquette#Trimming
That's not inline style's fault, that's pure laz
Hello,
What do you think about allowing some text after the words "recheck no
bug"? EG to include a snippet from the log showing the failure has been
at least briefly investigated before attempting a recheck. EG:
recheck no bug
Compute node failed to spawn:
2014-07-15 12:18:09.936 | 3f1
On Tue, Jul 22, 2014 at 9:18 PM, Jay Dobies wrote:
> What are everyone's feelings on adding a 1 spec review per week requirement
> for cores?
Averaged over the standard 90d period I presume?
+1 here.
Alexis
--
Nova Engineer, HP Cloud. AKA lealexis, lxsli.
___
As a new OpenStack contributor, +1 for lower barriers to entry. It's
helpful for OS to inform editor style and I don't believe in the
arguments to remove them.
> Why remove them?
> * we could shrink our codebase by a little bit.
Why do you want to shrink it? Simplify, sure, but modelines are not
Hi Mike,
Not 100% sure what you're asking for but have you seen these stats?
http://russellbryant.net/openstack-stats/
Alexis (lxsli)
--
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB
Often in Nova we introduce an option defaulted off (so as not to break
people) but then we want to make it default in the next release.
Someone suggested an opt flag to mark this but I don't know what impact
they wanted it to have. IE how the user should be alerted about the
presence of these flag
Sylvain Bauza said on Wed, Nov 18, 2015 at 04:48:50PM +0100:
> >This is just for the case of "we're going to change the default on the
> >next release". I think in that case, a release note is the right thing.
> >We don't need new fancy code for that.
>
> I usually hate saying just +1 in an email,
We just had a fun discussion in IRC about whether foreign keys are evil.
Initially I thought this was crazy but mordred made some good points. To
paraphrase, that if you have a scale-out app already it's easier to
manage integrity in your app than scale-out your persistence layer.
Currently the No
gord chung said on Thu, Nov 19, 2015 at 11:59:33PM -0500:
> just to clarify, the idea doesn't involve tailoring the notification
> payload to ceilometer, just that if a producer is producing a
> notification it knows contains a useful datapoint, the producer
> should tell someone explicitly 'this d
gord chung said on Fri, Nov 20, 2015 at 01:32:02PM -0500:
> On 20/11/15 11:33 AM, Alexis Lee wrote:
> >why would a producer spit out non-useful datapoints? If no-one cares
> >or will ever care, it simply shouldn't be included.
>
> ... right now the
> producer is j
Julien Danjou said on Fri, Nov 20, 2015 at 05:52:59PM +0100:
> On Fri, Nov 20 2015, Alexis Lee wrote:
> > We just had a fun discussion in IRC about whether foreign keys are evil.
> > Initially I thought this was crazy but mordred made some good points. To
> > paraphrase, tha
Matt Riedemann said on Fri, Nov 20, 2015 at 12:58:55PM -0600:
> On 11/20/2015 10:19 AM, Alexis Lee wrote:
> >Should we drive one way or the other, or just put up with mixed-mode?
> For the record, I hate the mixed mode.
+1
> >What should be the policy for new relations?
>
Jordan Pittier said on Mon, Nov 23, 2015 at 11:59:35AM +0100:
> Is the DB the limiting factor of openstack performance ? De we have hard
> evidence of this ? We need numbers before acting otherwise it will be an
> endless discussion.
Properly parallelised workers scale linearly. Persistent systems
Dmitry Tantsur said on Tue, May 17, 2016 at 09:54:02AM +0200:
> >I'd like to retry 314573 in a few weeks, so cooperation and helping
> >getting any leftover cases of 'verbose' out of source trees would be
> >much appreciated.
>
> Let me use this thread as a reminder: the goal of that deprecation
>
Hi,
I have a spec: https://review.openstack.org/227766
and implementation: https://review.openstack.org/316162
for adding a spooling logger to oslo.log. Neither is merged yet, reviews
welcome.
Looking at how I'd actually integrate this into Nova, most classes do:
LOG = logging.getLogger(__na
Doug Hellmann said on Tue, May 24, 2016 at 02:53:51PM -0400:
> Rather than forcing SpoolManager to be a singleton, maybe the thing
> to do is build some functions for managing a singleton instance (or
> one per type or whatever), and making that API convenient enough
> that using the spool logger d
Doug Hellmann said on Wed, May 25, 2016 at 11:06:35AM -0400:
> Excerpts from Alexis Lee's message of 2016-05-25 13:46:05 +0100:
> > def some_method(ctx):
> > log = tools.get_api_logger(ctx) or LOG
>
> That "or" statement in some_method() seems to imply though that
> when spool logging is o
I see a few reviews still open:
https://review.openstack.org/#/c/315868 - designate
https://review.openstack.org/#/c/315655 - devstack
https://review.openstack.org/#/c/317579 - glance
https://review.openstack.org/#/c/317556 - glance_store
Please could these get some attention?
>From browsing cod
Doug Hellmann said on Wed, May 25, 2016 at 11:56:55AM -0400:
> But that leaves it up to the application or library author to have to
> make that call for every log message, which makes logging more
> complicated.
Almost all messages generated while processing a request should only go
to the reques
Doug Hellmann said on Thu, May 26, 2016 at 10:16:31AM -0400:
> I'm not sure silencing all messages for successful requests is a good
> idea. That was not my understanding of the intent of this work, for
> sure. I thought the idea was to run the spool logger at debug, but
> maintain the other normal
Doug Hellmann said on Mon, Jun 13, 2016 at 03:11:17PM -0400:
> I'm trying to pull together some information about contributions
> that OpenStack community members have made *upstream* of OpenStack,
> via code, docs, bug reports, or anything else to dependencies that
> we have.
https://github.com/e
Joshua Harlow said on Mon, May 02, 2016 at 05:30:32PM -0700:
> Mutable config progress + mutable logging + mutable
> ***
>
> Etherpad @ https://etherpad.openstack.org/p/newton-oslo-mutables
Sorry for missing this session :|
No travel funding this ti
Doug Hellmann said on Tue, May 10, 2016 at 09:28:30AM -0400:
> Excerpts from Alexis Lee's message of 2016-05-10 10:25:24 +0100:
> > Joshua Harlow said on Mon, May 02, 2016 at 05:30:32PM -0700:
> > > - Desire to create a simple logging config like 'json' that will
>
> I'm planning to work on that wi
Doug Hellmann said on Wed, May 11, 2016 at 08:45:16AM -0400:
> Yes, handler, sorry.
>
> I thought they were only unconfigured if the flag was set to do that,
> and that your patch had the disable_existing_loggers flag set to not do
> it? Maybe I misunderstood the full meaning of the flag, though,
Marian Horban said on Thu, Dec 10, 2015 at 03:33:26PM +0200:
> Are there some progress with reloading configuration?
> Could we restore oslo-config review https://review.openstack.org/#/c/213062/
> ?
Hi Marian,
I'm also working on this, you might find
https://review.openstack.org/#/c/251471/ inte
Vladislav Kuzmin said on Tue, Dec 15, 2015 at 04:26:32PM +0300:
> I want to specify all my option in yaml file, because it is much more
> readable. But I must use ini file, because oslo.log using
> logging.config.fileConfig for reading the config file (
> https://github.com/openstack/oslo.log/blob/
Thierry Carrez said on Mon, Aug 03, 2015 at 02:57:39PM +0200:
> 1. we can maintain a Changelog document directly in the source code.
> Rather than being straightly backported from master, commits with
> significant changes would be amended to additionally modify that document.
Wouldn't this cause
Dugger, Donald D said on Mon, Aug 03, 2015 at 05:39:49AM +:
> Also note that, although many capabilities can be represented by
> simple key/value pairs (e.g. the presence of a specific special
> instruction) that is not true for all capabilities (e.g. Numa topology
> doesn't really fit into thi
Kekane, Abhishek said on Wed, Aug 12, 2015 at 08:59:02AM +:
> I have submitted a nova-specs for liberty but as it is not approved I have
> moved it under liberty/backlog.
>
> Now mitaka specs directory is added in nova-specs.
> Should it be ok to move nova-specs from specs/liberty/backlog/app
Thierry Carrez said on Fri, Aug 21, 2015 at 04:56:37PM +0200:
> Tag-every-commit:
> (+) Conveys clearly that every commit is consumable
> (-) Current tooling doesn't support this, we need to write something
> (-) Zillions of tags will make tags ref space a bit unusable by humans
>
> Time to time t
Vedsar Kushwaha said on Sat, Aug 29, 2015 at 09:30:05AM +0530:
> *i just want to understand as to how the request goes from the api-call to
> the nova-api and so on after that.*
For a code-level walkthrough:
http://docs-draft.openstack.org/67/210467/7/check/gate-nova-docs/51ee4c9//doc/build/h
Now with committer names.
Matt Riedemann said on Thu, Oct 01, 2015 at 01:27:38PM -0500:
> Here are the commits in liberty that had the UpgradeImpact tag:
% git log --format='%h %<(18,trunc)%cn %s' -i --grep UpgradeImpact \
remotes/origin/stable/kilo..remotes/origin/stable/liberty
0b49934
Markus Zoeller said on Fri, Oct 16, 2015 at 03:33:37PM +0200:
> > >Would it be possible to create a "prio" label to help sorting out
> stuff?
+1 to this!
> > I guess topics could be used but those are overwritten on every new
> > PS.
>
> The topics survive a new patch set, as far as I observed
Andrew Laski said on Mon, Jun 01, 2015 at 09:26:33AM -0400:
> However what these parameters give users, versus orchestrating
> outside of Nova, is the ability to have the instances all scheduled
> as a single block.
We should seek to provide this via persistent claims. IE add to the
API something
Alexis Lee said on Tue, Jun 02, 2015 at 11:28:03AM +0100:
> Paul Murray tells me there was a blueprint for this some time ago, but
> I can't find a spec for it. I'm interested in pushing this, I'll put up
> a spec at some point unless someone beats me to it.
Oops, found it
Ed Leafe said on Mon, Jun 01, 2015 at 07:40:17AM -0500:
> We need to update our concept of a resource internally in Nova, both
> in the DB and in code, and stop thinking that every request should
> have a flavor.
If you allocate all the memory of a box to high-mem instances, you may
not be billing
Robert Collins said on Wed, Jun 03, 2015 at 11:12:35AM +1200:
> So I'd like us to really get our heads around the idea that folk are
> able to make promises ('I will only commit changes relevant to the DB
> abstraction/transaction management') and honour them. And if they
> don't - well, remove the
Good summary, Ed!
Ed Leafe said on Wed, Jun 03, 2015 at 07:53:02AM -0500:
> > I totally agree the scheduler doesn't have to know anything about
> > flavors though. We should push them out to request validation in the
> > Nova API. This can be considered part of cleaning up the scheduler API.
>
> T
Chris Friesen said on Thu, Jun 04, 2015 at 10:57:54PM -0600:
> On 06/04/2015 05:23 PM, Zane Bitter wrote:
> > I have personally been using:
> >
> > Implements: partial-blueprint x
> >
> >but I don't actually care much. I would also be fine with:
> >
> > Partially-Implements: blueprint x
>
> If
Walter A. Boring IV said on Mon, Feb 22, 2016 at 11:47:16AM -0800:
> I'm trying to follow this here. If we want all of the projects in
> the same location to hold a design summit, then all of the
> contributors are still going to have to do international travel,
> which is the primary cost for at
Sean Dague said on Wed, Feb 04, 2015 at 09:51:30AM -0500:
> As there has been a bunch of concern around patches getting lost or
> stuck, I wanted to re-announce the fact that we've got a dedicated slot
> at the weekly Nova meeting for just those sorts of things.
The slot turned into everyone talki
Chris Friesen said on Wed, Feb 04, 2015 at 05:35:55PM -0600:
> it can be very difficult to determine whether
> a given flavor/image is bootable within the network
This implies to me that what you'd really like is to be able to ask the
scheduler whether a given flavor/image is bootable. The Gantt t
Ruby Loo said on Wed, Feb 25, 2015 at 11:26:56AM -0500:
> I was wondering what people thought about patches that only fix grammatical
> issues or misspellings in comments in our code.
For my money, a patch fixing nits has value but only if it fixes a few.
If it's a follow-up patch it should fix al
John Griffith writes:
> ​Should we just rename this thread to "Sensitivity training for
> contributors"?
Culture plays a role in shaping ones expectations here. I was lucky
enough to grow up in open source culture, so I can identify an automated
response easily and I don't take it too seriously.
Salvatore Orlando said on Tue, Mar 03, 2015 at 08:21:08PM +0100:
> Is common sense an option here?
Common sense is never an option :)
Mainly because it's situational and hence arises out of shared culture
and expectations, so those not indoctrinated into the group yet get
scolded for lacking comm
Doug Hellmann said on Wed, Mar 04, 2015 at 11:10:31AM -0500:
> I used to use email to track such things, but I have reached the point
> where keeping up with the push notifications from gerrit would consume
> all of my waking time.
Jim said if his patch was auto-abandoned, he would not find out. T
Robert Collins said on Thu, Apr 09, 2015 at 11:26:28AM +1200:
> Neutron was using 'unittest', but we depend on the fixes in cPython
> 3.5, which are backported in unittest2. We should not use 'unittest'
> itself anywhere in OpenStack, only 'unittest2'.
Can this be a hacking check or similar, to pr
James Slagle said on Tue, May 05, 2015 at 07:57:46AM -0400:
> I also plan to remove Alexis Lee from core, who previously has
> expressed that he'd be stepping away from TripleO for a while. Alexis,
> thank you for reviews and contributions!
Just confirming this is fine by me. Th
I propose the ant, known for discovering probabilistic graph traversal
algorithms.
My other thought, the bee, has already been taken by refstack.
lxsli
__
OpenStack Development Mailing List (not for usage questions)
Unsubsc
Markus Zoeller said on Mon, Aug 08, 2016 at 01:29:49PM +0200:
> On 08.08.2016 13:07, Alexis Lee wrote:
> > I propose the ant, known for discovering probabilistic graph traversal
> > algorithms.
> >
> > My other thought, the bee, has already been taken by refstack.
&g
75 matches
Mail list logo