> On 4 Mar 2016, at 15:40, gordon chung wrote:
>
>> One part of the documentation set that we were missing was a guide to how to
>> migrate from ceilometer to a ceilometer/gnocchi combination (which I
>> understand is the ultimate architecture). We would like to migrate the
>> historical data
HTML version:
http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160304/
SuccessBot Says
===
* Ttx: Mitaka-3 is done.
* Odyssey4me: OpenStack-Ansible Liberty 12.0.7 is released [1].
* johnthetubaguy: Nova is down to four pending blueprints for feature
I meant exactly that if you're not using venv for glance testing and
want to use testing tools shipped that have the wrappings of run_test or
even tox then asking packagers to write new scripts for doing the same
thing seems odd.
My question still stands: who is still using run_test towards this
p
On 04/03/16 14:12 -0500, Nikhil Komawar wrote:
Surely you can directly use the standard libraries to test systemwide
but I am more curious to know if there are some who are still using
run_tests wrappings that exist for to ease the pain a bit.
Oh, sorry if I came off wrong. What I meant is that
Hey all,
We're testing OpenStack Liberty on an ESX host and it installs fine. When
attempting to create a VM, receiving an error:
*libvirtError: invalid argument : could not find capabilities for
domaintype=kvm*
VMware environment is ESX 5.5:
*Capabilities*
nestedHVSupported = true
Intel VT-X
Surely you can directly use the standard libraries to test systemwide
but I am more curious to know if there are some who are still using
run_tests wrappings that exist for to ease the pain a bit.
On 3/4/16 12:41 PM, Flavio Percoco wrote:
> On 04/03/16 11:59 -0500, Nikhil Komawar wrote:
>> I think
On 04/03/16 16:40, "gordon chung" wrote:
>> One part of the documentation set that we were missing was a guide to how to
>> migrate from ceilometer to a ceilometer/gnocchi combination (which I
>> understand is the ultimate architecture). We would like to migrate the
>> historical data we
On 04/03/16 11:59 -0500, Nikhil Komawar wrote:
I think the hard question to me here is:
Do people care about testing code on system installs vs. virtual env?
run_tests does that and for some cases when you want to be extra sure
about your CICD nodes, packaging and upgrades, the problem is solved
+1
On Fri, Mar 4, 2016 at 12:30 PM, Matt Jarvis
wrote:
> +1
>
> On 4 March 2016 at 17:21, Robert Starmer wrote:
>
>> If fixing a typo in a document is considered a technical contribution,
>> then I think we've already cast the net far and wide. ATC as used has
>> become a name implying you're t
+1
On 4 March 2016 at 17:21, Robert Starmer wrote:
> If fixing a typo in a document is considered a technical contribution,
> then I think we've already cast the net far and wide. ATC as used has
> become a name implying you're trying to make OpenStack better, more
> useable, and more functional
There is a better explanation in the OpenStack docs :-) with an example how to
get 50% slower (not something my users ask for often)
cpu_quota & cpu_period seems to give it according to
http://docs.openstack.org/admin-guide-cloud/compute-flavors.html
Tim
On 04/03/16 15:59, "Jonathan Proul
If fixing a typo in a document is considered a technical contribution, then
I think we've already cast the net far and wide. ATC as used has become a
name implying you're trying to make OpenStack better, more useable, and
more functional for those who would use/deploy (and fix, update, enhance)
it.
So when a user manages a discussion across a group of operators, who's
input is then fed into the development teams who are developing the
software, and in such a way are supporting the development cycle, would
those downstream users (I'm not touching the code), not also be ATCs? The
discussions a
On Fri, Mar 04, 2016 at 12:20:44PM +, Jeremy Stanley wrote:
:On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:
:[...]
:> Upstream contributors are represented by the Technical Committee
:> and vote for it. Downstream contributors are represented by the
:> User Committee and (imho) sho
I think the hard question to me here is:
Do people care about testing code on system installs vs. virtual env?
run_tests does that and for some cases when you want to be extra sure
about your CICD nodes, packaging and upgrades, the problem is solved.
Are packagers using tox to this purpose?
On 3
Just for information, this is what I asked:
Fishbowl slots (Wed-Thu): 2
Workroom slots (Tue-Thu): 3
Contributors meetup (Fri): 1 if possible
Let's see if it's possible, I've been told it will be decided over the
next days.
On 02/24/2016 10:30 AM, Emilien Macchi wrote:
> Puppet OpenStack folks,
>
On 2016-03-04 16:34:27 +0200 (+0200), Maish Saidel-Keesing wrote:
[...]
> By saying that someone who contributes to OpenStack - but doing so by
> not writing code are not entitled to any technical say in what
> directions OpenStack should pursue or how OpenStack should be governed,
> is IMHO a weir
The keystone team did the same during Liberty while we were moving towards
using oslo.* projects instead of oslo-incubator [0]. We also noticed that
they were rarely used, and we did not go through a deprecation process
since these are developer tools. We're still finding a few spots in our
docs t
> One part of the documentation set that we were missing was a guide to how to
> migrate from ceilometer to a ceilometer/gnocchi combination (which I
> understand is the ultimate architecture). We would like to migrate the
> historical data we have stored in ceilometer.
>
> The main line documen
Isn't this more nuanced than simply 'upstream' and 'downstream' ?
Characterising downstream as "people who help others using OpenStack, by
moderating Ops meetups, by filing bugs, by answering questions on Ask, by
contributing a blogpost, etc...". is an extremely broad church.
My assumption about t
hi Mike,
the actual frequency of alerts corresponds to the frequency of alarm
evaluations[1]. the evaluation frequency defaults to 60s but can be
changed by setting 'evaluation_interval' option in your conf file.
On 03/03/2016 5:20 PM, Mike Smith wrote:
> We are using Ceilometer to tell us whe
On Fri, Mar 04, 2016 at 11:52:33AM +0800, gustavo panizzo (gfa) wrote:
:On Thu, Mar 03, 2016 at 03:52:49PM -0500, Jonathan Proulx wrote:
:>
:> I have a user who wants to specify their libvirt CPU type to restrict
:> performance because they're modeling embeded systems.
:>
:> I seem to vaguely rec
On 03/04/16 14:20, Jeremy Stanley wrote:
> On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:
> [...]
>> Upstream contributors are represented by the Technical Committee
>> and vote for it. Downstream contributors are represented by the
>> User Committee and (imho) should vote for it.
>
On 2016-03-04 10:02:36 +0100 (+0100), Thierry Carrez wrote:
[...]
> Upstream contributors are represented by the Technical Committee
> and vote for it. Downstream contributors are represented by the
> User Committee and (imho) should vote for it.
[...]
Right, this brings up the other important poi
Hey Folks,
I'm looking at doing some cleanups in our repo and I would like to start by
deprecating the `run_tests` script and the contents in the `tools/` dir.
As far as I can tell, no one is using this code - we're not even using it in the
gate - as it was broken until recently, I believe. The
On 04/03/16 10:47, James Page wrote:
> Added a bug task for the Kilo UCA - this should be picked up in the next
> round of kilo updates for the UCA.
>
I cherry-picked the fix into Red Hat OpenStack version 7, tracking bug is
https://bugzilla.redhat.com/show_bug.cgi?id=1314698
Matthias
Added a bug task for the Kilo UCA - this should be picked up in the next
round of kilo updates for the UCA.
On Fri, 4 Mar 2016 at 08:35 Matt Jarvis
wrote:
> This thread is a great example of the value of the midcycle meetups :)
>
> On 4 March 2016 at 08:09, Saverio Proto wrote:
>
>> Thanks for
Jeremy Stanley wrote:
On 2016-03-03 10:41:45 -0800 (-0800), Stefano Maffulli wrote:
[...]
I suggest not to create a separate category, and reuse ATC. Active
Technical Contributor always meant to include any contribution of
technical nature, including legal, operations, documentation, user
storie
This thread is a great example of the value of the midcycle meetups :)
On 4 March 2016 at 08:09, Saverio Proto wrote:
> Thanks for merging the patch so quickly ! I will try today to build
> new ubuntu packages and and for feedback at UCA.
>
> > But yes, thank you for pointing this out. Bug fixes
Thanks for merging the patch so quickly ! I will try today to build
new ubuntu packages and and for feedback at UCA.
> But yes, thank you for pointing this out. Bug fixes are mostly
> backported to Liberty release, in some rare cases Kilo might get a fix
> as well.
This is an endless discussion :
30 matches
Mail list logo
