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 wo
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 coff
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 libv
Richard Jones writes:
> On 12 November 2014 18:17, Matthias Runge 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
>
>
> They're trying to re
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
>>
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 get
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 - w
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 t
Richard Jones 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 interface for Swi
Fine for me.
On Wed, Nov 12, 2014 at 8:51 AM, Sylvain Bauza 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:
I'll be there!
Henry
On 12 Nov 2014, at 02:29, Adam Young 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 questions relat
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"
To: "OpenStack Development Mailing List (not for usage
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, wher
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 Hang
On 12 November 2014 09:53, marios 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 bandwidth c
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
d
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 migration,
Sounds like a security/identity/secrets mashup might be on the cards – should
be fun!
-Rob
From: Morgan Fainberg
mailto:morgan.fainb...@gmail.com>>
Reply-To: OpenStack List
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 11 November 2014 21:52
To: OpenStack List
mailto:openstack-de
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:
Whe
On 06 Nov 2014, at 12:20, Przemyslaw Kaminski 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 of simple job to rem
On 11/12/2014 11:06 AM, Salvatore Orlando wrote:
> On 12 November 2014 09:53, marios 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 likely
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 client
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 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
>>
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
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 ethe
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 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 stack
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 av
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,
Ste
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 res
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 y
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 this?https://blueprints.launchpad.net/heat/+spec/intrins
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"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
>
> 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 schedule. We were really stretched thin
> d
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 lib,
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 wrote:
> Hi,
>
> Please have a look into these:
> https://p
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, Pradip
count me also.
On Wed, Nov 12, 2014 at 2:48 PM, Irena Berezovsky
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,
>
> In
On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter 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 such issue?
Also no
Thanks, Zane for pointing out the right mailing list.
--pradip
On Wed, Nov 12, 2014 at 6:35 PM, Zane Bitter 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 we want it sear
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 e
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 Ope
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 wrote:
> - Original Message -
> > From: "Zhipeng Huang"
> > To: "OpenStack Development Mailing List (not f
On 11/12/2014 02:40 AM, Richard Jones wrote:
> On 12 November 2014 18:17, 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.
>
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 (
https://github.com/openstack-dev/d
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 paskporr
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 trans
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 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 OpenStac
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 reviews.
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 test
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 with
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 devs
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
___
On 12/11/14 08:24, Stan Lagun wrote:
On Wed, Nov 12, 2014 at 3:50 PM, Zane Bitter mailto: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
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
solut
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.
>
> A
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 fro
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
wrote:
> 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
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
To: "OpenStack Development Mailing List (not for us
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 a
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 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 re-review existin
On Wed, Nov 12, 2014 at 4:11 AM, Chris Dent 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 least until it is
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 ju
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
c
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 packa
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 no
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
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
serv
On 12 Nov 2014, at 17:56, foss geek 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
>
> In enviro
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 no
-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 p
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 oth
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,
an
On Nov 12, 2014, at 10:42 AM, Zane Bitter
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 reasons. I
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
> >>> com
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,
M
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 unders
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 dist
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 teste
+1!
2014-11-12 9:31 GMT-03:00 Flavio Percoco :
> 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
>
On Nov 12, 2014, at 1:30 PM, David Kranz 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 would like to
> On Nov 12, 2014, at 12:45 PM, Dan Smith 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 think thes
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 developm
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 mai
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 o
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 osl
On Nov 12, 2014, at 3:29 PM, Andreas Jaeger 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 Down”
> On Nov 12, 2014, at 3:32 PM, Doug Hellmann 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 from oslo.foo to
>
1 - 100 of 146 matches
Mail list logo
