On 12/11/14 08:40, Richard Jones wrote:
I believe the nodeenv method of installing node solves this, as it's
entirely local to the development environment.
See below, this touches package build as well.
I will have to go through all dependencies and do a review, if those are
On 11/11/14 08:02, Richard Jones wrote:
There were some discussions around tooling. We're using xstatic to
manage 3rd party components, but there's a lot missing from that
environment. I hesitate to add supporting xstatic components on to the
already large pile of work we have to do, so would
On 12/11/14 09:28, Matthias Runge wrote:
Looking at es5-shim, it pulls in additional 28 dependent packages, json3
has 12 dependencies (including a circular dependency, one circular
depencency in dependencies),
Please scratch that. I'll need to look at that a bit deeper (after
another coffee)
On Tue, Nov 11, 2014 at 01:59:12PM +0800, Chen CH Ji wrote:
see the error value of diagnostics is huge , but I don't think my disk is
that bad ... is this wrong info or wrong usage of libvirt?
Also, all the disk has same error number curious me , any guide ?
Considering you are using
Richard Jones r1chardj0...@gmail.com writes:
On 12 November 2014 18:17, Matthias Runge mru...@redhat.com wrote:
Sigh, this nonsense doesn't go away? This is the third time the same
issue comes up.
jshint is NOT free software.
https://github.com/jshint/jshint/blob/master/src/jshint.js#L19
On 11/12/2014 08:04 AM, marios wrote:
On 12/11/14 04:17, Clint Byrum wrote:
Just as a counter-point: The entire reason that a mid-cycle is an
important thing to do is to achieve higher bandwidth communication between
contributors. We can do Hangouts all the time and that's certainly a
useful
Folks,
as we all getting hurry with features landing before Feature Freeze
deadline, we destabilize master. Right after FF, we must be focused on
stability, and bug squashing.
Now we are approaching Soft Code Freeze [1], which is planned for Nov 13th.
Master is still not very stable, and we are
Count me in
From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, November 11, 2014 3:47 PM
To: OpenStack List
Subject: [openstack-dev] [Neutron] Translation technical debt
Hi,
In order to enforce our translation policies -
http://docs.openstack.org/developer/oslo.i18n/guidelines.html -
Hello all,
I will write here some things I have noticed in the mailing list and on which I
can contribute.
Npm and Bower:
bower and npm are here for two separate things, the first one is here to handle
the dependencies of the webapp (angular, es5shim, d3.js and so on), meanwhile
npm is here
Richard Jones r1chardj0...@gmail.com writes:
Hi all,
At the summit last week, we developed a plan for moving forward with
modernising Horizon's UI using AngularJS. If you weren't at that meeting
and are interested in helping out with this effort please let me know!
I have been working on an
Fine for me.
On Wed, Nov 12, 2014 at 8:51 AM, Sylvain Bauza sba...@redhat.com wrote:
Le 11/11/2014 23:07, Matt Riedemann a écrit :
On 11/11/2014 3:51 PM, Matt Riedemann wrote:
On 11/11/2014 3:50 PM, Matt Riedemann wrote:
On 11/11/2014 3:04 PM, Andrew Laski wrote:
We had a great
I'll be there!
Henry
On 12 Nov 2014, at 02:29, Adam Young ayo...@redhat.com wrote:
On 11/11/2014 08:18 PM, Morgan Fainberg wrote:
I am trying to pin down a location for our mid-cycle meetup, I need to get
an idea of who will be joining us at the Keystone meetup. I’ve included a
couple
Thanks Martin, I remember that eslint was mentioned at some point to replace
jshint. Maybe, it can be interesting to look at this, the extension possibility
is a major point for a switch.
- Original Message -
From: Martin Geisler mar...@geisler.net
To: OpenStack Development Mailing List
Hi Jaume,
The concept of provider router is useful as it maps what actually already
happens in several infrastructures. I am not entirely sure that this
however implies we need to expose new API constructs and change the
topology API.
The provider router perhaps can exist in a concealed way,
On 12/11/14 11:18, Anita Kuno wrote:
On 11/12/2014 08:04 AM, marios wrote:
On 12/11/14 04:17, Clint Byrum wrote:
Just as a counter-point: The entire reason that a mid-cycle is an
important thing to do is to achieve higher bandwidth communication between
contributors. We can do Hangouts all
On 12 November 2014 09:53, marios mar...@redhat.com wrote:
On 12/11/14 11:18, Anita Kuno wrote:
On 11/12/2014 08:04 AM, marios wrote:
On 12/11/14 04:17, Clint Byrum wrote:
Just as a counter-point: The entire reason that a mid-cycle is an
important thing to do is to achieve higher
On Tue, 11 Nov 2014, Adam Young wrote:
My suggestion, from a while ago, was to have a naming scheme that deconflicts
putting all of the services onto a single server, on port 443.
+1
The current state of affairs is indeed weird.
Is this something that ought to be considered in the api-wg's
Great job, Mike, thanks!
Doug, as for migration from sqlalchemy-migrate to Alembic - at the moment
it's hard to realize this because we suppose to keep backward compatibility
with available migrations. I'd like to re-review existing approach with
Mike and Roman, create road-map for this
Sounds like a security/identity/secrets mashup might be on the cards – should
be fun!
-Rob
From: Morgan Fainberg
morgan.fainb...@gmail.commailto:morgan.fainb...@gmail.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, 11
Hi
As promised at the dev sessions I have made a doodle so we can vote for
a venue for the midcycle meetup.
Here is the link:
https://doodle.com/b9m4bf8hvm3mna97
Note: I have added one more option to the doodle no meetup. I understand
that this is a big financial burden and I'd like to get an
hi, i run command nova evacuate failed, anyone can help point out direction?
steps:
1.run two compute host A and B
2.run instance vm01 on host A, shutdown host A
3.run command nova evacuate --on-shared-storage vm01 B
My analysis is:
On 06 Nov 2014, at 12:20, Przemyslaw Kaminski pkamin...@mirantis.com wrote:
I didn't mean a robust monitoring system, just something simpler.
Notifications is a good idea for FuelWeb.
I’m all for that, but if we add it, we need to document ways to clean up space.
We could also add some kind
On 11/12/2014 11:06 AM, Salvatore Orlando wrote:
On 12 November 2014 09:53, marios mar...@redhat.com wrote:
On 12/11/14 11:18, Anita Kuno wrote:
On 11/12/2014 08:04 AM, marios wrote:
On 12/11/14 04:17, Clint Byrum wrote:
Just as a counter-point: The entire reason that a mid-cycle is an
Hello,
We come across this:
http://docs.openstack.org/developer/heat/pluginguide.html
Looks like it solves three of the purposes listed below:
1. Define a custom resource type with properties and attributes
2. Register the resource to the Hear orchestrator
3. Write a driver/plugin (most
Chris Dent wrote:
On Tue, 11 Nov 2014, Adam Young wrote:
My suggestion, from a while ago, was to have a naming scheme that deconflicts putting all of the
services onto a single server, on port 443.
+1
The current state of affairs is indeed weird.
It is, and as BUIs move more towards
On 12/11/14 12:55, Anita Kuno wrote:
On 11/12/2014 11:06 AM, Salvatore Orlando wrote:
On 12 November 2014 09:53, marios mar...@redhat.com wrote:
On 12/11/14 11:18, Anita Kuno wrote:
On 11/12/2014 08:04 AM, marios wrote:
On 12/11/14 04:17, Clint Byrum wrote:
Just as a counter-point: The
On 11/11/2014 3:04 PM, Andrew Laski wrote:
We had a great discussion on cells at the summit which is captured at
https://etherpad.openstack.org/p/kilo-nova-cells. One of the tasks we
agreed upon there was to form a subgroup to co-ordinate this effort
and
report progress to the Nova meeting
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
On 11/11/2014 03:02 PM, Richard Jones wrote:
Hi all,
At the summit last week, we developed a plan for moving forward with
modernising Horizon's UI using AngularJS. If you weren't at that meeting
and are interested in helping out with this effort please let me know!
The relevant etherpad
Team,
Do we meet Wednesday or Thursday this week?
Best,
Itai
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Wed, Nov 12, 2014 at 9:33 PM, Alexis Lee alex...@hp.com wrote:
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
Team,
I've just submitted a spec for backup/restore API [1][2]
Please share your thoughts.
[1] https://review.openstack.org/#/c/133933/
[2] https://blueprints.launchpad.net/magnetodb/+spec/backup-restore-api
--
Best regards,
Illia Khudoshyn,
Software Engineer, Mirantis, Inc.
38, Lenina
Hi all,
Please note there will be no Telco Working Group (formerly NFV subteam) meeting
this week. We will pick up next Wednesday @ 1400 UTC in #openstack-meeting-alt.
I will also send an email with a more APAC/US West friendly alternate time than
the current Thursday one shortly.
Thanks,
Hi Itai,
I just sent an email about this - no meeting this week (would have been
Thursday), we will pick up next Wednesday. I am in the process of selecting a
new meeting time for the Thursday alternate and will also be sending out an
email about the CI needs shortly :).
Thanks,
Steve
-
HI,
in order to make sure some critical Haproxy backends are running (like
mysql or keystone) before proceeding with deployment, we use execs like [1]
or [2].
We're currently working on a minor improvements of those execs, but there
is another approach - we can replace those execs with puppet
Greetings,
Zaqar team will pick up its regular meetings next Monday at 15 UTC.
We'll keep alternating time, therefore the meeting after the next one
will be at 21 UTC.
The team meets in the #openstack-meeting-3 channel and we keep the
agenda in the wiki[0]. Do feel free to add items to it that
On 12/11/14 06:33, Alexis Lee wrote:
I would much prefer to resurrect the previous proposal for adding
conditionals and then see what is still missing than to just dive
straight in to embedding a whole other language in HOT.
Do you mean
On 12/11/14 06:48, Angus Salkeld wrote:
(it's nice that there would be a consistent user experience
between these projects -mistral/heat/murano).
It's actually potentially horrible, because you introduce potential
quoting issues when you embed mistral workbooks in Heat templates or
pass Heat
- Original Message -
From: Zhipeng Huang zhipengh...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Hi Team,
I knew we didn't propose this in the design summit and it is kinda rude in
this way to jam a topic into the
Hi,
Please have a look into these:
https://pypi.python.org/pypi/oslo.concurrency
https://pypi.python.org/pypi/oslo.middleware
Am I supposed to dig into the code to double-guess what the library is
doing, and write that in the debian/control? Guys, please make the
effort *before* we release a
Thomas,
We hear your frustration, bugs were logged yesterday
https://bugs.launchpad.net/oslo.middleware/+bug/1391551
https://bugs.launchpad.net/oslo.concurrency/+bug/1391550
thanks,
dims
On Wed, Nov 12, 2014 at 7:55 AM, Thomas Goirand tho...@goirand.fr wrote:
Hi,
Please have a look into
The developer mailing list is not for usage questions. Please ask this
on ask.openstack.org - I'm sure a lot of people will be interested in
the answer and we want it searchable for them in future. Feel free to
ping me with a link when you've posted it.
cheers,
Zane.
On 12/11/14 06:00,
count me also.
On Wed, Nov 12, 2014 at 2:48 PM, Irena Berezovsky ire...@mellanox.com
wrote:
Count me in
*From:* Gary Kotton [mailto:gkot...@vmware.com]
*Sent:* Tuesday, November 11, 2014 3:47 PM
*To:* OpenStack List
*Subject:* [openstack-dev] [Neutron] Translation technical debt
Hi,
On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter zbit...@redhat.com wrote:
It's actually potentially horrible, because you introduce potential
quoting issues when you embed mistral workbooks in Heat templates or pass
Heat templates to Murano.
Could you please give an example of template with
Thanks, Zane for pointing out the right mailing list.
--pradip
On Wed, Nov 12, 2014 at 6:35 PM, Zane Bitter zbit...@redhat.com wrote:
The developer mailing list is not for usage questions. Please ask this on
ask.openstack.org - I'm sure a lot of people will be interested in the
answer and
On 11/12/2014 07:50 AM, Zane Bitter wrote:
On 12/11/14 06:48, Angus Salkeld wrote:
(it's nice that there would be a consistent user experience
between these projects -mistral/heat/murano).
It's actually potentially horrible, because you introduce potential
quoting issues when you embed
On 11/12/2014 02:17 AM, Matthias Runge wrote:
On 11/11/14 10:53, Jiri Tomasek wrote:
Hey,
Thanks for writing this up!
The Storyboard project has successfully integrated these tools into
the OpenStack CI environment.
OpenStack CI and distributors are different, because OpenStack CI does
Hi Steve,
We are hammering out the details right now, and will send it out to the
community,like real soon :) Thanks for the comment!
On Wed, Nov 12, 2014 at 1:53 PM, Steve Gordon sgor...@redhat.com wrote:
- Original Message -
From: Zhipeng Huang zhipengh...@gmail.com
To: OpenStack
On 11/12/2014 02:40 AM, Richard Jones wrote:
On 12 November 2014 18:17, Matthias Runge mru...@redhat.com wrote:
On 11/11/14 10:53, Jiri Tomasek wrote:
Hey,
Thanks for writing this up!
The Storyboard project has successfully integrated these tools into
the OpenStack CI environment.
Hi Liu,
3rd party CI isn't for driver cert test, it is for checking driver with
every review request to Cinder. Every driver vendor should setup own 3rd
party CI.
To get Cinder Driver Cert results you need to run cinder_driver_cert.sh
script from devstack repo (
Hello
I am working on an api for a new feature in nova, but I am wondering
what is the correct way to add a new extension: should it be supported
by v2, v3 or both?
BR
--
Pasquale Porreca
DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)
Mobile +39 3394823805
Skype
Hi Gary,
I posted the patch-set addressing ML2 plugin
https://review.openstack.org/#/c/130992/ .
I feel it is becoming long chain. It would be great we should first start
approving those patch-sets first rather than approving other bug-fix
related patch-set and ensure that all fulfills i18n
On 11/12/2014 02:35 PM, Monty Taylor wrote:
On 11/12/2014 02:40 AM, Richard Jones wrote:
On 12 November 2014 18:17, Matthias Runge mru...@redhat.com wrote:
On 11/11/14 10:53, Jiri Tomasek wrote:
Hey,
Thanks for writing this up!
The Storyboard project has successfully integrated these tools
If you have tempest running in the third party CI with every commit,
you don't need a cert test result. The CI is very much the preferred
method.
To post a result, open a bug with 'Huawei XXX driver cert result; and
the logs attached.
Other than, that, it is just a matter of waiting for
https://review.openstack.org/#/c/102315/ was merged yesterday, it
creates a non functional trove python client. (There are currently no
tests in python trove client to see if the commands even run after a
code change).
This means the trove devstack exercise can't work.
Which means everything
For the REST API to be visible from browser it should either be on the same
domain and port or it should implement CORS spec (Cross-site HTTP requests,
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS).
If REST API implements CORS, then every HTTP request will be preceded
On 11/12/2014 09:17 AM, Sean Dague wrote:
https://review.openstack.org/#/c/102315/ was merged yesterday, it
creates a non functional trove python client. (There are currently no
tests in python trove client to see if the commands even run after a
code change).
This means the trove devstack
Let's skip the ML2 IRC meeting this week, while some people are still
traveling and/or recovering. Next week I hope to have good discussions
regarding a common ML2 driver repo vs. separate repos per vendor, as
well as the ML2 BPs for Kilo.
-Bob
Hello Salvatore,
thanks for the response. Rest of the responses inline:
El 12/11/14 a las 10:49, Salvatore Orlando escribió:
Hi Jaume,
The concept of provider router is useful as it maps what actually already
happens in several infrastructures. I am not entirely sure that this
however
Sean, I'm looking into this and have proposed
https://review.openstack.org/#/c/133958/ as an interim measure. As soon as the
trove gate passes I'll try and get a couple of other votes and have that change
merged.
Dims and I had a short chat on IRC and weren't able to come up with a quick
Hi all,
Today we have a next workflow about NTP in Fuel:
1. When someone deploy a master node, we need to somehow operate with NTP
and set upstream NTP servers to Fuel NTP daemon on master node.
2. NTP will enabled by default and set to default upstream values (from
ntp.org pool).
3. If user will
Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
On 11/11/14 13:34, Ryan Brown wrote:
I am strongly against allowing arbitrary Javascript functions for
complexity reasons. It's already difficult enough to get meaningful
errors when you up your YAML syntax.
Agreed,
On 11/11/2014 08:02 AM, Richard Jones wrote:
Hi all,
At the summit last week, we developed a plan for moving forward with
modernising Horizon's UI using AngularJS. If you weren't at that
meeting and are interested in helping out with this effort please let
me know!
The relevant etherpad
Should we just block the deployment until the NTP is fixed so they
know they need to fix it?
On Wed, Nov 12, 2014 at 6:06 PM, Stanislaw Bogatkin
sbogat...@mirantis.com wrote:
Hi all,
Today we have a next workflow about NTP in Fuel:
1. When someone deploy a master node, we need to somehow
I have filled out the form and very much look forward to attending!!!
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From: Morgan Fainberg morgan.fainb...@gmail.com
To: OpenStack Development
Andrew,
That just shifts the error into Nailgun which is forced to examine NTP
settings of the host. With docker containerization, it makes detecting
this much more difficult. Erroring during fuelmenu is the only chance
where a user can effectively set the NTP parameters correctly. We
could write
Hello fuelers,
I would like to request you merging CR [1] which implements blueprint [2].
It is a nice UX feature we really would like to have in 6.0. On the other
side, the implementation is really small: it is a small piece of puppet
which runs a shell script. The script always exits with 0, so
On Nov 12, 2014, at 5:12 AM, Victor Sergeyev vserge...@mirantis.com wrote:
Great job, Mike, thanks!
Doug, as for migration from sqlalchemy-migrate to Alembic - at the moment
it's hard to realize this because we suppose to keep backward compatibility
with available migrations. I'd like to
On Wed, Nov 12, 2014 at 4:11 AM, Chris Dent chd...@redhat.com wrote:
The current state of affairs is indeed weird.
Is this something that ought to be considered in the api-wg's
discussions?
It does and I think that is where the proposed mapping of URL-to-API should
reside. Proposed at
My point is that quoting problem do exists probably but it exists even
without YAQL being used anywhere.
For example consider Mistral workbook containing value: { get_attr:
[my_instance, first_address] }. get_attr in Mistral may have nothing to to
with Heat's get_attr and even if it is it may be
I'm currently investigating the feasibility of a generic
compare-and-swap feature for NovaObject.save(). This post isn't about
that, but that's the larger context.
As a preliminary step towards that goal, I've started by investigating
how Nova objects are saved today. Ideally there would be some
On 12/11/14 15:12, Jiri Tomasek wrote:
Approach on using Xstatic packages vs Js tooling:
As only problem with using js tooling should be just actual packaging of
it, I think it makes sense to use these tools and make development
simpler then going other way around and using Xstatic packages
Nikolay,
You're right. We will need to store the events in order to re-publish.
How about a separate Event model? The events are written to the DB by the
same worker that publishes the event. The retention policy for these
events is then managed by a config option.
Winson
An initial inconsistency I have noticed is that some objects refresh
themselves from the database when calling save(), but others don't.
I agree that it would be ideal for all objects to behave the same in
this regard. I expect that in practice, it's not necessary for all
objects to do this,
The Oslo team is pleased to announce the release of oslo.vmware 0.7.0.
This release includes several bug fixes
(https://launchpad.net/oslo.vmware/+milestone/0.7.0) as well as many other
changes:
1661a0a Updated from global requirements
33f6002 Imported Translations from Transifex
8b1f97b Do
On 12/11/14 10:10, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
On 11/11/14 13:34, Ryan Brown wrote:
I am strongly against allowing arbitrary Javascript functions for
complexity reasons. It's already difficult enough to get meaningful
errors when you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/11/14 16:22, Dan Smith wrote:
An initial inconsistency I have noticed is that some objects
refresh themselves from the database when calling save(), but
others don't.
I agree that it would be ideal for all objects to behave the same
in
I am reading Fuel reference-architecture documentation in the below link:
http://docs.mirantis.com/openstack/fuel/fuel-5.1/reference-architecture.html#openstack-environment-architecture
In the page no 2 note says:
*Note*
*In environments that use vCenter as the hypervisor, the Nova-compute
On 12 Nov 2014, at 17:56, foss geek thefossg...@gmail.com wrote:
I am reading Fuel reference-architecture documentation in the below link:
http://docs.mirantis.com/openstack/fuel/fuel-5.1/reference-architecture.html#openstack-environment-architecture
In the page no 2 note says:
Note
neophy,
This is a requirement of the fuel deployment with vCenter selected as
the compute hyper-visor. In this case the nova-compute service would
be configured on the controller nodes and the fuel ui would not allow
you to deploy kvm computes.
You can post configure additional services on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Ihar
On 11/11/14 19:39, Ihar Hrachyshka wrote:
there is a series of Neutron backports in the Juno queue that are
intended to significantly improve service performance when
handling security groups (one of the issues that are main pain
On 11/12/2014 05:18 PM, Julie Pichon wrote:
On 12/11/14 15:12, Jiri Tomasek wrote:
Approach on using Xstatic packages vs Js tooling:
As only problem with using js tooling should be just actual packaging of
it, I think it makes sense to use these tools and make development
simpler then going
Hi James,
This is awesome. I seem to have misplaced my 540-node cluster. ;-)
Is it possible for you to also patch in
https://review.openstack.org/#/c/132372/ ? In my rally testing of port
retrieval, this one probably made the most significant improvement.
On Nov 12, 2014 9:26 AM, James Page
I personally favour having consistent behaviour across the board. How
about updating them all to auto-refresh by default for consistency,
but adding an additional option to save() to disable it for particular
calls?
I think these should be two patches: one to make them all auto-refresh,
and
On Nov 12, 2014, at 10:42 AM, Zane Bitter zbit...@redhat.com
wrote:
On 12/11/14 10:10, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
On 11/11/14 13:34, Ryan Brown wrote:
I am strongly against allowing arbitrary Javascript functions for
complexity
Excerpts from Zane Bitter's message of 2014-11-12 08:42:44 -0800:
On 12/11/14 10:10, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
On 11/11/14 13:34, Ryan Brown wrote:
I am strongly against allowing arbitrary Javascript functions for
complexity
Hi,
As for the Devstack it requires some rebasing work (not necessarily
straightforward) in order to push the changes upstream. As for the neutron,
it should not be difficult to port FreeBSD networking support (we have some
code in our forked repos) from nova-network to neutron plugin.
Regards,
Code has started going into tempest for several projects
(nova,neutron,keystone) to allow removal of xml support in kilo. There
have been many (heated) off and on threads on this list over the years.
I'm sure many projects would like to do this, but there is evidence that
not all have an
During our “Graduation Schedule” summit session we worked through the list of
modules remaining the in the incubator. Our notes are in the etherpad [1], but
as part of the Write it Down” theme for Oslo this cycle I am also posting a
summary of the outcome here on the mailing list for wider
Hi all,
We had some discussions last week - particularly in the Nova NFV design session
[1] - on the subject of ensuring that telecommunications and NFV-related
functionality has adequate continuous integration testing. In particular the
focus here is on functionality that can't easily be
+1!
2014-11-12 9:31 GMT-03:00 Flavio Percoco fla...@redhat.com:
Greetings,
Zaqar team will pick up its regular meetings next Monday at 15 UTC.
We'll keep alternating time, therefore the meeting after the next one
will be at 21 UTC.
The team meets in the #openstack-meeting-3 channel and we
On Nov 12, 2014, at 1:30 PM, David Kranz dkr...@redhat.com wrote:
Code has started going into tempest for several projects
(nova,neutron,keystone) to allow removal of xml support in kilo. There have
been many (heated) off and on threads on this list over the years. I'm sure
many projects
On Nov 12, 2014, at 12:45 PM, Dan Smith d...@danplanet.com wrote:
I personally favour having consistent behaviour across the board. How
about updating them all to auto-refresh by default for consistency,
but adding an additional option to save() to disable it for particular
calls?
I
The outcome of the “Should Oslo continue to use alpha versions” session at the
summit [1] was unclear, so I would like to continue the discussion here.
As we discussed at the summit, the primary reason for marking Oslo library
releases as alphas was to indicate that the library is under
The oslo.messaging session at the summit [1] resulted in some plans to evolve
how oslo.messaging works, but probably not during this cycle.
First, we talked about what to do about the various drivers like ZeroMQ and the
new AMQP 1.0 driver. We decided that rather than moving those out of the
On 11/12/2014 08:06 PM, Doug Hellmann wrote:
During our “Graduation Schedule” summit session we worked through the list of
modules remaining the in the incubator. Our notes are in the etherpad [1],
but as part of the Write it Down” theme for Oslo this cycle I am also
posting a summary of
We rather quickly came to consensus at the summit that we should drop the use
of namespace packages in Oslo libraries [1]. As far as I could tell, everyone
was happy with my proposed approach [2] of moving the code from oslo.foo to
oslo_foo and then creating a backwards-compatibility shim in
On Nov 12, 2014, at 3:29 PM, Andreas Jaeger a...@suse.com wrote:
On 11/12/2014 08:06 PM, Doug Hellmann wrote:
During our “Graduation Schedule” summit session we worked through the list
of modules remaining the in the incubator. Our notes are in the etherpad
[1], but as part of the Write it
On Nov 12, 2014, at 3:32 PM, Doug Hellmann d...@doughellmann.com wrote:
We rather quickly came to consensus at the summit that we should drop the use
of namespace packages in Oslo libraries [1]. As far as I could tell, everyone
was happy with my proposed approach [2] of moving the code
On 11/12/2014 02:11 PM, Steve Gordon wrote:
NUMA
We still need to identify some hardware to run third party CI for the
NUMA-related work, and no doubt other things that will come up. It's
expected that this will be an interim solution until OPNFV resources
can be used (note cdub
1 - 100 of 145 matches
Mail list logo
