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.
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)
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.
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
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
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
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
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
Hi, I'm working on being able to reload a service's config file. This
may be useful for EG turning debug logging on/off*, tweaking live
migration parameters and changing the number of workers.
Operators, which options would you like to be mutable (reloadable)? I'm
interested in Nova for now, if
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 =
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
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,
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
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
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
Alexis Lee said on Mon, Feb 01, 2016 at 04:54:39PM +:
> I have a spec up to allow config files to be specified as YAML instead
> of INI: https://review.openstack.org/273468
Sorry to do this so soon after first posting but - I've let this die.
Initial feedback has been very ne
Hi operators,
I have a spec up to allow config files to be specified as YAML instead
of INI: https://review.openstack.org/273468
The main benefit from my perspective is being able to use YAML tooling
to transform config (EG as part of an Ansible run). Crudini doesn't work
well with MultiStrOpts.
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 (
>
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/
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 jus
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?
>
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
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
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
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
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
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
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
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
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
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:
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
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
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 this
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 a
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.
This
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 we need one,
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 their
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, thanks Paul:
https
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
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
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. Thanks!
Alexis
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
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.
John Griffith john.griffi...@gmail.com 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
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 all
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 talking
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
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,
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 mailing
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
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
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 the
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
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
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, and
On Tue, Jul 22, 2014 at 9:18 PM, Jay Dobies jason.dob...@redhat.com 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.
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
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 |
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.
Yuriy Taraday said on Tue, May 20, 2014 at 01:37:29PM +0400:
On Mon, May 19, 2014 at 8:38 PM, Alexis Lee alex...@hp.com 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 think you can get
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
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
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, for
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 what an
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 get
Miller, Mark M (EB SW Cloud - RD - 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 the
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
values:
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
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
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
74 matches
Mail list logo
