There were no objections, so, we'll make a meeting tomorrow at 1400 UTC
On Thu, Nov 27, 2014 at 1:43 PM, Sergey Lukjanov slukja...@mirantis.com
wrote:
If there will be no objections till the next week, we'll try the new time
(14:00UTC) next week.
On Thu, Nov 27, 2014 at 4:06 AM, Zhidong Yu
Hello Anteaya,
A meeting between 8:00 - 16:00 UTC time will be great (Israel).
Thanks
Omri
-Original Message-
From: Joshua Hesketh [mailto:joshua.hesk...@rackspace.com]
Sent: Wednesday, December 03, 2014 9:04 AM
To: He, Yongli; OpenStack Development Mailing List (not for usage
The confirmation modal on the top of the other modal is weird and
cumbersome. I think disabling clicking outside space (staic backdrop) is
the right way to go.
Anton
On Tue, Dec 2, 2014 at 8:30 PM, Thai Q Tran tqt...@us.ibm.com wrote:
I like David's approach, but having two modals (one for the
Hi All,
I'd like to accomplish 2 things with this message:
1) Unblock (one way or another) https://review.openstack.org/#/c/123957
2) Create some form of consensus on when it's okay to add temporary code to
nova to work around bugs in external utilities.
So some background on this specific
Hi All,
Is it possible for Kilo nova controller to control the Juno compute nodes?
Is this scenario supported naturally by the nova mechanism in the design
and codes level?
--
Best Regards!
Junhong, Li
The use case we were thinking about is a Network Function (e.g. IMS
Nodes) implementation in which the high availability is based on
OpenSAF. In this scenario there is an Active/Standby cluster of 2 System
Controllers (SC) plus several Payloads (PL) that boot from network,
controlled by the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, folks:
I clone the stable/icehouse branch of ceilometer project from github,
use tox -r -e py26 to run unit tests on CentOS 6.5 system.
Unfortunately there are many cases failed. You can find the output in
test.log, and pip.log is the output of
On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong lijh.h...@gmail.com wrote:
Hi All,
Is it possible for Kilo nova controller to control the Juno compute nodes?
Is this scenario supported naturally by the nova mechanism in the design
and codes level?
Yes,
We gate on making sure we can run Kilo
Sam,
It really looks like you're having old *.pyc files locally in this repo
(probably left from other branch testing)... As I understood, you just
cloned clean repo and first tests you've ran were these ones? If no,
removing all *.pyc files will help you, otherwise I have no clear idea why
you
Hi Joe,
Thank you for your confirmative answer and the wonderful gate testing
pipeline.
On Wed, Dec 3, 2014 at 5:38 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong lijh.h...@gmail.com wrote:
Hi All,
Is it possible for Kilo nova controller to
Alan Pevec wrote:
General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to include in the
release.
https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z
So it looks like we should hold on that,
Hi Joe,
Just want to confirm one more question, in the gate testing, is the
neutron/cinder/glance Kilo or Juno. Or in another word, is the controller
in gate testing an all-in-one controller?
On Wed, Dec 3, 2014 at 5:49 PM, Li Junhong lijh.h...@gmail.com wrote:
Hi Joe,
Thank you for your
We had used Flask in the fuel-stats. It was easy and pleasant and all
project requirements was satisfied. And I saw difficulties and workarounds
with Pecan, when Nick integrated it into Nailgun.
So +1 for Flask.
On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov nmar...@mirantis.com
wrote:
Hi,
I'm picking up this thread from a few months ago, as I have a
requirement for a private external network and after doing some testing
today came to the conclusion that this isn't currently possible. Rats.
On Tue, 2014-10-14 at 17:42 +, A, Keshava wrote:
Hi,
Across these private
Doug Hellmann wrote:
On Dec 2, 2014, at 5:41 PM, Alan Pevec ape...@gmail.com wrote:
General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to include in
the release.
There is a current blueprint under discussion[1] which would have covered
the external network access control as well, however it looks like the
scope is going to have to be reduced for this cycle so it will be limited
to shared networks if it's accepted at all.
1.
Hi all,
Lately I've been spending more time looking at tripleo and doing some
reviews. I'm particularly interested in helping the no-mergepy and
subsequent puppet-software-config implementations mature (as well as
improving overcloud updates via heat).
Since Tomas's patch landed[1] to enable
On Wed, Dec 03, 2014 at 10:03:06AM +0100, Sahid Orentino Ferdjaoui wrote:
On Tue, Dec 02, 2014 at 07:44:23PM +, Mooney, Sean K wrote:
Hi all
I have submitted a small blueprint to allow filtering of available memory
pages
Reported by libvirt.
Can you address this with
Congratulations to Henry and Kevin, very well deserved!,
keep up the good work! :)
Miguel Ángel Ajo
On Wednesday, 3 de December de 2014 at 09:44, Oleg Bondarev wrote:
+1! Congrats, Henry and Kevin!
On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery mest...@mestery.com
On Wed, Dec 3, 2014 at 11:53 AM, Li Junhong lijh.h...@gmail.com wrote:
Hi Joe,
Just want to confirm one more question, in the gate testing, is the
neutron/cinder/glance Kilo or Juno. Or in another word, is the controller
in gate testing an all-in-one controller?
Great question. In our
Well, I think if the general direction is to make Fuel using OpenStack
tools and libraries as much as it's possible, that makes sense to use
Pecan. Otherwise I'd prefer to swap web.py with Flask.
Sincerely yours,
Ivan Kliuk
On 12/2/14 16:55, Igor Kalnitsky wrote:
Hi, Sebastian,
Thank you
Hi all,
It seems that a process with a survey for neutron core
election/removal was about to take place [1]. Has it been applied for
this proposal?
This proposal has been hardly discussed during neutron meetings
[2][3]. Many cores agree that the number of reviews shouldn't be the
only metrics.
Hi
I am very sympathetic to this view. We have a patch in hand that improves the
situation. We also have disagreement about the ideal situation.
I +2'd Ian's patch because it makes things work better than they do now. If we
can arrive at an ideal solution later, great, but the more I think
On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin akuri...@mirantis.com
wrote:
Hi!
While working on fixing wrong import in novaclient v3 shell, I have found
that a lot of commands, which are listed in V3 shell(novaclient.v3.shell),
are broken, because appropriate managers are missed from V3
The only useful paradigm to write in Flask is MethodView's for me [1]
because decorators seem hard to refactor for large projects. Please look
at adding URLs -- one has to additionally specify methods to match those
from the MethodView -- this is code duplication and looks ugly.
It seems
On 3 Dec 2014, at 10:00 pm, Joe Gordon joe.gord...@gmail.com wrote:
On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin akuri...@mirantis.com wrote:
Hi!
While working on fixing wrong import in novaclient v3 shell, I have found
that a lot of commands, which are listed in V3
Hi,
is there a way to get access to the slides from the DVR session of the
Paris summit? Unfortunately the slides in the video are not readable.
Speakers were Swaminathan Vasudevan, Jack McCann, Vivekanandan,
Narasimhan, Rajeev Grover, Michael Smith. So maybe one of you can post
them on
Hi, all
I am a graduate student in Peking University, our lab do some research on open
source projects.
This is our introduction: https://passion-lab.org/
Now we need openstack issues data for research, I found the issues list:
https://bugs.launchpad.net/openstack/
I want to download the
Additionaly to what Przemek wrote, also Pecan is released more often, IMHO
documentation is better written, and described a lot of possibilities of
modification, also as Lukasz wrote in previous thread that Pecan is used in
openstack.
So I'm also for Pecan
Best regards,
Kamil S.
On Wed, Dec 3,
Thank for answers.
I sent a patch to novaclient : https://review.openstack.org/#/c/138694/
On Wed, Dec 3, 2014 at 1:59 PM, Christopher Yeoh cbky...@gmail.com
javascript:_e(%7B%7D,'cvml','cbky...@gmail.com'); wrote:
On 3 Dec 2014, at 10:00 pm, Joe Gordon joe.gord...@gmail.com
On Wed, Dec 03, 2014 at 08:20:45PM +0800, zfx0...@gmail.com wrote:
Hi, all
I am a graduate student in Peking University, our lab do some research on
open source projects.
This is our introduction: https://passion-lab.org/
Now we need openstack issues data for research, I found the
I don't like that Flask uses a global request object [3].
Przemyslaw, actually Pecan does use global objects too. BTW, what's
wrong with global objects? They are thread-safe in both Pecan and
Flask.
IMHO documentation is better written, and described a lot of possibilities of
modification
I
2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com:
I don't like that Flask uses a global request object [3].
Przemyslaw, actually Pecan does use global objects too. BTW, what's
wrong with global objects? They are thread-safe in both Pecan and
Flask.
To be fair, Pecan could
Yeah, didn't notice that. Honestly, I'd prefer both to be accessible as
instance attributes just like in [1] but it's more of taste I guess.
[1]
http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request
P.
On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote:
Hi,
you could take a look at Stackalytics and how this website communicates
with launchpad.
https://wiki.openstack.org/wiki/Stackalytics/HowToRun
Best,
Angelo
On 03/12/2014 13:41, Louis Taylor wrote:
On Wed, Dec 03, 2014 at 08:20:45PM +0800, zfx0...@gmail.com wrote:
Hi, all
I am a
+1 to changing the behaviour to ‘static'. Modal inside a modal is potentially
slightly more useful, but looks messy and inconsistent, which I think outweighs
the functionality.
Rob
On 2 Dec 2014, at 12:21, Timur Sufiev
tsuf...@mirantis.commailto:tsuf...@mirantis.com wrote:
Hello,
Dear colleagues,
We surely may take into account the beauty of the code in both cases
(as for me, Pecan loses here, too) and argue about global objects and
stuff, but I'm trying to look at amount of men and time we need to
move to one of these frameworks.
I wouldn't say our API is badly
Hi
Unfortunately a flavor + aggregate is not enough for our use case as it is
still possible for the tenant to misconfigure a vm.
The edge case not covered by flavor + aggregate that we are trying to prevent
is as follows.
The operator creates an aggregate containing the nodes that require
Hi all,
enable_new_services in nova.conf seems to allow add new compute nodes in
disabled state:
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L507-L508,
so it would allow to check everything first, before allowing production
workloads host a VM on it. I've filed a bug to
On 12/03/2014 11:11 AM, Steven Hardy wrote:
Hi all,
Lately I've been spending more time looking at tripleo and doing some
reviews. I'm particularly interested in helping the no-mergepy and
subsequent puppet-software-config implementations mature (as well as
improving overcloud updates via
Hi Mike,
We've got the similar option in Cinder too:
https://github.com/openstack/cinder/blob/master/cinder/db/api.py#L58
Regards,
Ivan Kolodyazhny
On Wed, Dec 3, 2014 at 3:31 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Hi all,
enable_new_services in nova.conf seems to allow add new
Mathieu:
The peer review proposal was NOT about removing core reviewers, that
is very clear in the proposal. The peer review proposal was about
deciding as a team what it means to be a core reviewer, and ensuring
core reviewers are doing that. I still plan to do try out the peer
review process in
On Dec 2, 2014, at 7:48 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:
On 12/2/2014 12:33 PM, Ben Nemec wrote:
We've discovered a couple of problems as a result of this release. pep8
in most/all of the projects using oslo.concurrency is failing due to the
move out of the oslo
I never used Flask and Pecan personally so I can only rely from what I saw
in this thread and in both projects docs.
I don't have strong opinion, just want to share some thoughts.
I think that as a part of OpenStack community we should stick with Pecan
and because of the same reason
we can have a
I don’t have an opinion for now but do have some thoughts instead.
We use Pecan in Ironic.
I could say that it’s pretty nice when one needs to make something simple but
requires some manual job to be done in more or less sophisticated cases.
On the other hand we have that the Pecan team is quire
Hello Folks
The Oslo team is pleased to announce the release of oslo.db 1.2.0.
This release includes several bug fixes as well as many other changes:
$ git log --abbrev-commit --pretty=oneline --no-merges 1.1.0..1.2.0
f740e3b Imported Translations from Transifex
ca1ad56 Make test_models pass on
A recent proposed test to tempest was making explicit calls to the nova
extension discovery api rather than using test.requires_ext. The reason
was because we configure tempest.conf in the gate as 'all' for
extensions, and the test involved an extension that was new in Juno. So
the icehouse
On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote:
I think that as a part of OpenStack community we should stick with
Pecan and because of the same reason we can have a bigger impact how
future versions of Pecan will look.
Yes, this. ++
-jay
___
It would be great to look at some obvious points where Pecan is better
than Flask despite of the fact that it's used by the community. I
still don't see a single and I don't think the principle jump from
the cliff if everyone does works well in such cases.
On Wed, Dec 3, 2014 at 5:53 PM, Jay
Being able to make some impact on Pecan is an advantage for sure. But there are
other aspects in choosing a web framework and I’d rather discuss them.
Let’s not think about what is used in other OpenStack projects for a moment and
discuss technical details.
On 03 Dec 2014, at 15:53, Jay Pipes
On 12/03/2014 10:16 AM, Nikolay Markov wrote:
It would be great to look at some obvious points where Pecan is better
than Flask despite of the fact that it's used by the community. I
still don't see a single and I don't think the principle jump from
the cliff if everyone does works well in such
On Wed, Dec 03, 2014 at 09:43:41AM -0500, David Kranz wrote:
A recent proposed test to tempest was making explicit calls to the nova
extension discovery api rather than using test.requires_ext. The reason was
because we configure tempest.conf in the gate as 'all' for extensions, and
the test
Hello all
Unfortunately, my complete inability to process daylight savings time changes
meant I was one hour late for today's TelcoWG meeting so couldn't participate
in the discussion of use cases, including the one I submitted on Session Border
Control. Thanks to eavesdrop.openstack.org I've
However, the OpenStack community is also about a shared set of tools,
development methodologies, and common perspectives.
I completely agree with you, Jay, but the same principle may be
applied much wider. Why Openstack Community decided to use its own
unstable project instead of existing
Hi everyone,
Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, December 4th at 17:00 UTC in the #openstack-meeting
channel.
The agenda for tomorrow's meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome
On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague s...@dague.net wrote:
We've hit two interesting issues this week around multiple projects
installing into the paste pipeline of a server.
1) the pkg_resources explosion in grenade. Basically ceilometer modified
swift paste.ini to add it's own code
A month or two ago I started gathering differencies between Flask and
Pecan, let's take a look at technical details. Maybe there are some
things that are already fixed in current versions of Pecan, feel free
to comment.
Hi there. I've been looking into a tricky point, and hope I can succeed
in expressing it clearly here...
I believe it is the case, even when using a committedly Neutron-based
networking implementation, that Nova is still involved a little bit in
the networking setup logic. Specifically I mean
On 12/03/2014 10:57 AM, Lance Bragstad wrote:
On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
We've hit two interesting issues this week around multiple projects
installing into the paste pipeline of a server.
1) the pkg_resources
On Fri, Nov 7, 2014 at 5:57 AM, Elizabeth K. Joseph
l...@princessleia.com wrote:
The OpenStack Infrastructure team will be hosting a virtual sprint in
the Freenode IRC channel #openstack-sprint for the Infrastructure User
Manual on December 1st starting at 15:00 UTC and going for 48 hours.
I didn't participate in that discussion, but here are topics on Flask
cons from your link. I added some comments.
- Cons
- db transactions a little trickier to manage, but possible #
what is trickier? Flask uses pure SQLalchemy or a very thin wrapper
- JSON built-in but not XML # the
+1. Well said. I second the applauding of the Fuel's development team's for
their changing of their communications patterns (that's never easy) and also
the desire for closer integration with the rest of the OpenStack community.
From: Jay Pipes
I've left some comments/corrections in this document re: pecan and what is
supports.
On 12/03/14 07:58 PM, Nikolay Markov wrote:
A month or two ago I started gathering differencies between Flask and
Pecan, let's take a look at technical details. Maybe there are some
things that are already
+1 for Kevin and Henry. Thanks for your continuous efforts so far and
it would be great additions to our community.
I also would like to say great thanks to Bob and Nachi.
It would be really nice if we see their activities in reviews soon.
We already understand your contributions and skills, so
I
Choosing the right instrument for the job in an open source community involves
choosing technologies that the community is familiar/comfortable with as well,
as it will allow you access to a greater pool of developers.
With that in mind then, I'd add:
Pro Pecan, blessed by the OpenStack
On 12/3/2014 3:49 AM, Li Junhong wrote:
Hi Joe,
Thank you for your confirmative answer and the wonderful gate testing
pipeline.
On Wed, Dec 3, 2014 at 5:38 PM, Joe Gordon joe.gord...@gmail.com
mailto:joe.gord...@gmail.com wrote:
On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong
Excerpts from Chris Jones's message of 2014-12-03 02:47:30 -0800:
Hi
I am very sympathetic to this view. We have a patch in hand that improves the
situation. We also have disagreement about the ideal situation.
I +2'd Ian's patch because it makes things work better than they do now. If
Hi Daniel thanks for your feedback.
After reading up a little more
http://docs.openstack.org/openstack-ops/content/scaling.html#segragation_methods
I now understand your original suggestion.
I believe that if the operator associates the aggregate directly to the flavor
As you suggested that
2014-12-02 17:15 GMT+01:00 Jay S. Bryant jsbry...@electronicjungle.net:
Cinder
https://review.openstack.org/137537 - small change and limited to the
VMWare driver
+1 I think this is fine to make an exception for.
one more Cinder exception proposal was added in StableJuno etherpad
*
Horizon
standing-after-freeze translation update, coming on Dec 3
This is now posted https://review.openstack.org/138798
David, Matthias, I'd appreciate one of you to have a quick look before
approving.
Cheers,
Alan
___
OpenStack-dev mailing list
Hi,
Poll is closed! Everyone please welcome: Pixie Boots, the new Ironic mascot!
Thanks for everyone that voted!
Cheers,
Lucas
On Mon, Dec 1, 2014 at 4:47 PM, Lucas Alvares Gomes lucasago...@gmail.com
wrote:
Ah forgot to say,
Please add your launchpad ID on the Name Field. And I will close
Neutron
https://review.openstack.org/136294 - default SNAT, see review for
details, I cannot distil 1liner :)
-1: I would rather fix the doc to match behavior, than change behavior
to match the doc and lose people that were relying on it.
Consensus is not to merge this and keep behavior.
I give +2 to Henry and Kevin. So, Congratulations Folks!
I have been working with both of them and great quality reviews are always
coming out from them.
Many thanks to Nachi and Bob for their hard work!
Edgar
On 12/2/14, 7:59 AM, Kyle Mestery mest...@mestery.com wrote:
Now that we're in the
On 03/12/14 20:22, Alan Pevec wrote:
Horizon
standing-after-freeze translation update, coming on Dec 3
This is now posted https://review.openstack.org/138798
David, Matthias, I'd appreciate one of you to have a quick look before
approving.
Cheers,
Alan
Alan, thanks for the heads-up
Hi
On 3 Dec 2014, at 18:41, Clint Byrum cl...@fewbar.com wrote:
What if the patch is reworked to leave the current trace-all-the-time
mode in place, and we iterate on each script to make tracing conditional
as we add proper logging?
+1
Cheers,
--
Chris Jones
Hi guys,
I'm using Devstack with vlan on the parameter Q_ML2_TENANT_NETWORK_TYPE and
while stacking, the quantun-agent (q-agt) breaks. I'm running it on an
Ubuntu Server 14.04.
For more details, here's my local.conf: http://pastebin.com/4scBGtpf.
The error that I recieve is the following:
Hey,
So this is a long running topic, but I want to bring it up again.
First, YES Cinder is still running a sample.conf. A lot of Operators
spoke up and provided feedback that this was valuable and they
objected strongly to taking it away. That being said we're going to
go the route of removing
So this -
https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
was clearly a violation of our 1 cycle for deprecation of config options.
I think that should be reverted, an oops release put out to fix it, and
then deprecate for 1.6.
If oslo libraries are
As of now third-party CI account creation is now self-serve. I think
this makes everybody happy.
What does this mean?
Well for a new third-party account this means you follow the new
process, outlined here:
http://ci.openstack.org/third_party.html#creating-a-service-account
If you don't have
Hi John,
Let me say first off that I 100% agree with the value of the sample config
being in-tree. Keystone has not removed it due to similar feedback I’ve
received. However, the issue is that *gating* on config changes for all
libraries that are included in the sample config is just a process
Reply to Valeriy below and to Marc further below...
On 12/03/2014 02:39 AM, Valeriy Ponomaryov wrote:
According to (2) - yes, analog of Cinder's manage/unmanage is not
implemented in Manila yet.
Manage/unmanage is a feature I'm very interested in seeing in Manila. I
suspect it will be
On 12/03/2014 02:45 PM, Sean Dague wrote:
So this -
https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
was clearly a violation of our 1 cycle for deprecation of config options.
I think that should be reverted, an oops release put out to fix it, and
On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
Hi John,
Let me say first off that I 100% agree with the value of the sample config
being in-tree. Keystone has not removed it due to similar feedback I’ve
received. However, the issue is that *gating* on config changes for all
libraries
On Dec 3, 2014, at 1:18 PM, Sean Dague s...@dague.net wrote:
On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
Hi John,
Let me say first off that I 100% agree with the value of the sample config
being in-tree. Keystone has not removed it due to similar feedback I’ve
received. However,
So folks, I had to put Alembic 0.7.1 out as I realized that the “batch” mode
was being turned on for autogenerate across the board in 0.7.0, and that was
not the plan.
So it is now out, and the builds are failing due to
https://launchpad.net/bugs/1397796 https://launchpad.net/bugs/1397796.
Ben Nemec wrote:
On 12/03/2014 02:45 PM, Sean Dague wrote:
So this -
https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
was clearly a violation of our 1 cycle for deprecation of config options.
I think that should be reverted, an oops release put out to
Whoops too many mailing lists.
Forwarded Message
Subject: Re: [OpenStack-Infra] [openstack-dev] [third-party]Time for
Additional Meeting for third-party
Date: Wed, 03 Dec 2014 17:25:05 -0500
From: Anita Kuno ante...@anteaya.info
To: openstack-in...@lists.openstack.org
On
What you are proposing sounds very reasonable. If I understand correctly,
the idea is to make Nova just create the TAP device and get it attached to
the VM and leave it 'unplugged'. This would work well and might eliminate
the need for some drivers. I see no reason to block adding a VIF type that
Thanks Mike,
I already gave your patch a +2. when the gate is broken there's no time for
nitpicking - those can come with a followup patch.
The patch is now spinning again against jenkins checks. As soon as it's
done we'll send it through the gate - and hopefully get a promotion for it.
I've just created the signup page for this event. Its here:
https://www.eventbrite.com.au/e/openstack-nova-juno-mid-cycle-developer-meetup-tickets-14767182039
Cheers,
Michael
On Wed, Oct 15, 2014 at 3:45 PM, Michael Still mi...@stillhq.com wrote:
Hi.
I am pleased to announce details for the
Sigh, sorry. It is of course the Kilo meetup:
https://www.eventbrite.com.au/e/openstack-nova-kilo-mid-cycle-developer-meetup-tickets-14767182039
Michael
On Thu, Dec 4, 2014 at 10:16 AM, Michael Still mi...@stillhq.com wrote:
I've just created the signup page for this event. Its here:
Congratulations Henry and Kevin. It has always been pleasure working with
you guys.
If I may express my opinion, Bob's contribution to ML2 has been quite
substantial. The kind of stability ML2 has achieved makes a statement of
his dedication to this work. I have worked very closely with Bob
On Wed, Dec 3, 2014 at 2:18 PM, Sean Dague s...@dague.net wrote:
On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
Hi John,
Let me say first off that I 100% agree with the value of the sample config
being in-tree. Keystone has not removed it due to similar feedback I’ve
received. However, the
You can download a database dump with (hopefully) information for all
Launchpad tickets corresponding to OpenStack, already organized and
ready to be queried:
http://activity.openstack.org/dash/browser/data/db/tickets.mysql.7z
(linked from
On Wed, 2014-12-03 at 10:11 +, Steven Hardy wrote:
Hi all,
Lately I've been spending more time looking at tripleo and doing some
reviews. I'm particularly interested in helping the no-mergepy and
subsequent puppet-software-config implementations mature (as well as
improving overcloud
Excerpts from Dan Prince's message of 2014-12-03 18:35:15 -0800:
On Wed, 2014-12-03 at 10:11 +, Steven Hardy wrote:
Hi all,
Lately I've been spending more time looking at tripleo and doing some
reviews. I'm particularly interested in helping the no-mergepy and
subsequent
Don't care either way, let's be consistent with other projects and raise this
concern in next weekly cross-project meeting [1] to see what all of the
projects mutually agree on. If there is no consensus, let's stick to what we
have.
@Louis: Can you please add that to the agenda of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dina,
As you say, it is caused by legacy .pyc files. I remove them all and
all tests are passed.
Thanks
Sam
On 12/03/2014 05:47 PM, Dina Belova wrote:
have unit tests failing in the new just cloned reposi
-BEGIN PGP SIGNATURE-
Version:
Hi,
so just having read a bunch of the libvirt driver numa code, I have a
concern. At first I thought it was a little thing, but I am starting
to think its more of a big deal...
We use the term cells to describe numa cells. However, that term has
a specific meaning in nova, and I worry that
Hi all,
I'm becoming increasingly concerned about all of the code paths
in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use
nova-baremetal rather than Ironic. We do not check nova-bm support in
CI, haven't for at least a month, and I'm concerned that parts of it
may be
1 - 100 of 105 matches
Mail list logo
