Hi,
For passing information from neutron to nova VIF Driver, you should use
binding:vif_details dictionary. You may not require new VIF_TYPE, but can
leverage the existing VIF_TYPE_OVS, and add ‘use_dpdk’ in vif_details
dictionary. This will require some rework of the existing libvirt vif_dr
On 9 July 2014 20:24, Sullivan, Jon Paul wrote:
>Incidentally, is there already way to review what votes my CI (or
> indeed anybody's) is casting via an openstack.org web interface?
>
>
>
> >>> You can look at the individual account dashboards in Gerrit, like:
> https://review.openstack.org/#
Hello Mark.
There are several patches for Postgresql are hanging at the review queue.
Here's useful link:
https://blueprints.launchpad.net/trove/+spec/postgresql-support
Contact point: Kevin Conway (you can ping him in IRC and ask if he needs
any help)
Best regards,
Denis Makogon
On Thu, Ju
We have an issue with neutron (and presumably elsewhere), where mysqldb and
eventlet may deadlock, until the mysqldb deadlock timer fires.
I believe it's responsible for ~all of these failures:
http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkxvY2sgd2FpdCB0aW1lb3V0IGV4Y2VlZGVkOyB0cnkgcmVzdGFydGluZy
Howdy!
I've been operating a shellci for a while now and overall it is very smooth.
The main new feature now is to automatically retrigger events that neither
definitely succeed (exit status 100) nor definitely fail (exit status 101).
In this case the CI will vote "0" with the logs and then autom
I hadn't realised until today that the BP window for new Nova specs in Juno
had closed, and I'm hoping I might get an exception for a minor, but I
think helpful, change in the way VIF plugging works.
At the moment, Neutron's plugin returns a binding_type to Nova when
plugging takes place, describi
We had a call between Andrew (@xarses), Vladimir Kuklin (@aglarendil) and
myself (@mihgen) today to finally sort out Neutron ML2 integration in Fuel.
We didn't have @xenolog on the call, but hopefully he is more or less fine
with all below, and kindly request him to confirm :)
Discussed following t
+1 from me.
Matt
> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com]
> Sent: 09 July 2014 16:52
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [TripleO] Proposal to add Jon Paul Sullivan and
> Alexis
> Lee to core review team
>
> Hello!
>
> I've been
Thanks Denis, will do!
On 10/07/14 19:23, Denis Makogon wrote:
Hello Mark.
There are several patches for Postgresql are hanging at the review queue.
Here's useful link:
https://blueprints.launchpad.net/trove/+spec/postgresql-support
Contact point: Kevin Conway (you can ping him in IRC and as
On 10 July 2014 10:06, Luke Gorrie wrote:
> The main new feature now is to automatically retrigger events that neither
> definitely succeed (exit status 100) nor definitely fail (exit status 101).
> In this case the CI will vote "0" with the logs and then automatically
> schedule a new test, up t
+1
El 10/07/2014 10:12, "Macdonald-Wallace, Matthew" <
matthew.macdonald-wall...@hp.com> escribió:
> +1 from me.
>
> Matt
>
> > -Original Message-
> > From: Clint Byrum [mailto:cl...@fewbar.com]
> > Sent: 09 July 2014 16:52
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-
As far as I know, Fuel CI for Fuel Library (deployments on CentOS simple &
Ubuntu HA) is fixed now.
For example,
https://review.openstack.org/#/c/103947/
https://review.openstack.org/#/c/103642/
passed CI hour or two ago.
However, there are still some issues in Ubuntu HA deployments on > 1
control
TL;DR: do we need to stabilize notifications behind a versioned
and discoverable contract?
Folks,
One of the issues that has been raised in the recent discussions with
the QA team about branchless Tempest relates to some legacy defects
in the OpenStack notification system.
Now, I don't p
Hi
+1
Cheers,
--
Chris Jones
> On 9 Jul 2014, at 16:52, Clint Byrum wrote:
>
> Hello!
>
> I've been looking at the statistics, and doing a bit of review of the
> reviewers, and I think we have an opportunity to expand the core reviewer
> team in TripleO. We absolutely need the help, and I thi
Confirmed.
Also, if you do not want to wait, just rebase your change or cherry-pick it
to the same branch. It could overload CI a bit because it will retrigger
all the CI tests, so if you have only one test that was failing consider
poking devops guys in #fuel-dev first.
On Thu, Jul 10, 2014 at
Hi All,
Please help to review this proposal and give me your comments. Thanks a
lot.
--
Best regard,
David Geng
--___
OpenStack-dev mailing list
OpenStack-d
Hi all,
===
tl;dr: Now that we agree on waiting for the split prereqs to be done, we
debate on if ResourceTracker should be part of the scheduler code and
consequently Scheduler should expose ResourceTracker APIs so that Nova
wouldn't own compute nodes resources. I'm proposing to first come with
R
The patch for bug 1329564 [1] merged about 11 hours ago.
>From [2] it seems there has been an improvement on the failure rate, which
seem to have dropped to 25% from over 40%.
Still, since the patch merged there have been 11 failures already in the
full job out of 42 jobs executed in total.
Of thes
On Wed, Jul 09, 2014 at 06:23:27PM -0400, Sean Dague wrote:
> The libvirt logs needed are huge, so we can't run them all the time. And
> realistically, I don't think they provided us the info we needed. There
> has been at least one fail on Dan's log hack patch for this scenario
> today, so maybe i
On 07/10/2014 10:58 AM, Jian Hua Geng wrote:
> Hi All,
>
> Please help to review this proposal and give me your comments. Thanks a lot.
Hi David,
Please don't send review requests to the list. For details see:
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html
Andrea
On 9.7.2014 17:52, Clint Byrum wrote:
So, I propose that we add jonpaul-sullivan and lxsli to the TripleO core
reviewer team.
+1
Jirka
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listin
Eugene (& list)
I just saw that you reassigned the bug to yourself recently , and that
the ideas described in the bug differ a bit from the idea that I had,
but I'd be willing to extend my spec to incorporate your design and spend
some time in the problem if you believe it's feasible.
I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/07/14 08:09, Angus Lees wrote:
> On 10 July 2014 00:59, Roman Podoliaka
> wrote:
>
>> Not sure what issues you are talking about, but I just replaced
>> "mysql" with "mysql+mysqlconnector" in my db connection string
>> in neutron.conf and "n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/07/14 11:07, Salvatore Orlando wrote:
> The patch for bug 1329564 [1] merged about 11 hours ago. From [2]
> it seems there has been an improvement on the failure rate, which
> seem to have dropped to 25% from over 40%. Still, since the patch
>
On Wed, 9 Jul 2014, Clint Byrum wrote:
> So, I propose that we add jonpaul-sullivan and lxsli to the TripleO core
> reviewer team.
Obviously I should declare an interest, but I think this'd be good.
+1
jan
--
Just because I have nothing to hide doesn't mean I have nothing to fear.
__
On Wed, Jul 09, 2014 at 10:33:26PM +, Randall Burt wrote:
> On Jul 9, 2014, at 4:38 PM, Zane Bitter
> wrote:
> > On 08/07/14 17:17, Steven Hardy wrote:
> >
> >> Regarding forcing deployers to make a one-time decision, I have a question
> >> re cost (money and performance) of the Swift approa
On 10 July 2014 11:27, Ihar Hrachyshka wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 10/07/14 11:07, Salvatore Orlando wrote:
> > The patch for bug 1329564 [1] merged about 11 hours ago. From [2]
> > it seems there has been an improvement on the failure rate, which
> > seem to
If I understand correctly, you are having it comment when there is a
retrigger due to an internal CI failure? If so, please don't do this
because it makes the Gerrit reviews very noisy and it provides nothing
relevant to the contributor submitting the patch.
Nobody wants a CI to report that it has
For log storage I would definitely start with compression since these are
just plain text. Make sure you enable gzip decompression in your web server
software so people can still view the log files in their browser.
Before spending tons of disk space on log storage, I would also have it
purge logs
On Wed, Jul 9, 2014 at 7:39 PM, Clint Byrum wrote:
> Excerpts from Yuriy Taraday's message of 2014-07-09 03:36:00 -0700:
> > On Tue, Jul 8, 2014 at 11:31 PM, Joshua Harlow
> > wrote:
> >
> > > I think clints response was likely better than what I can write here,
> but
> > > I'll add-on a few thi
Hi again Jon Paul,
My mistake! This seems to be exactly what I was looking for, thank you. (I
goofed the query which is why I thought it was lacking.)
Cheers :)
-Luke
On 10 July 2014 09:17, Luke Gorrie wrote:
> On 9 July 2014 20:24, Sullivan, Jon Paul wrote:
>
>>Incidentally, is there a
Wow Shihanzhang, truly awesome!,
Is the current implementation for https://review.openstack.org/#/c/104522/
also ready?, could you make it available?.
Good work!,
- Original Message -
>
> With the deployment 'nova + neutron + openvswitch', when we bulk create about
> 500 VM with a
As I've been staring at failures in the gate a lot over the past month,
we've managed to increasingly tune the tempest client for readability
and debugability. So when something fails in an API test, pin pointing
it's failure point is getting easier. The scenario tests... not so much.
Using the of
Hello Angus!
IMO, the simple answer on your question is - tests for eventlet and oslo.db
interaction should be in the same place, where eventlet and oslo.db
interact. :)
A little digression - we suppose, that oslo.db should neither know, nor
take care whether target projects use eventlet/gevent/O
Honestly, that seems weird to me.
oslo.db is built as a common layer for OpenStack services.
eventlet is used by most OpenStack services.
There are lots of known issues with eventlet vs. our db access patterns.
Knowing that the db layer works in the common OpenStack pattern seems
really importa
On Thu, Jul 10 2014, Eoghan Glynn wrote:
Hi Eoghan,
> So the purpose of this thread is simply to get a read on the appetite
> in the community for such an effort. At the least it would require:
>
> * trashing out the details in say a cross-project-track session at
>the K* summit
>
> * buy-i
I prefer IRC only.
As I am located in Israel and so are other Radware people, it is easier for us
to use IRC which is also more available from more devices and locations.
OpenStack has chosen IRC as a way to allow different people from different
places and different speaking capabilities to work
On 09/07/14 17:52, Clint Byrum wrote:
> Hello!
>
> I've been looking at the statistics, and doing a bit of review of the
> reviewers, and I think we have an opportunity to expand the core reviewer
> team in TripleO. We absolutely need the help, and I think these two
> individuals are well position
On 07/10/2014 05:03 AM, Daniel P. Berrange wrote:
> On Wed, Jul 09, 2014 at 06:23:27PM -0400, Sean Dague wrote:
>> The libvirt logs needed are huge, so we can't run them all the time. And
>> realistically, I don't think they provided us the info we needed. There
>> has been at least one fail on Dan
> > Note that the notifications that capture these resource state transitions
> > are a long-standing mechanism in openstack that ceilometer has depended
> > on from the very outset. I don't think it's realistic to envisage these
> > interactions will be replaced by REST APIs any time soon.
>
> I
Le jeudi 10 juillet 2014, 14:48:04 Yuriy Taraday a écrit :
> I'm not suggesting that taskflow is useless and asyncio is better (apple vs
> oranges). I'm saying that using coroutines (asyncio) can improve ways we
> can use taskflow and provide clearer method of developing these flows.
> This was mos
Tomas Sedovic said on Thu, Jul 10, 2014 at 02:26:06PM +0200:
> On 09/07/14 17:52, Clint Byrum wrote:
> +1 for both. However, some of the reviews show what I think is a
> worrying trend in TripleO core. Specifically, nitpicking and tendency to
> bikeshed.
Hi Tomas, thanks for your +1 and thoughts.
++
The ugly monkey patch approach is still working fine for my downstream
testing, but that's something I'd be happy to get rid of.
Something that may be worth considering is to have an abstraction layer on top
of tempest clients, to allow switching the actual implementation below:
- REST call
On Thu, Jul 10, 2014 at 08:32:37AM -0400, Sean Dague wrote:
> On 07/10/2014 05:03 AM, Daniel P. Berrange wrote:
> > On Wed, Jul 09, 2014 at 06:23:27PM -0400, Sean Dague wrote:
> >> The libvirt logs needed are huge, so we can't run them all the time. And
> >> realistically, I don't think they provid
+1 from me (while also declaring an interest).
-stephen
--
Stephen Mulcahy Systems/Software Engineer HP Cloud Phone: +353 91 754257
Postal Address: Hewlett Packard Galway Ltd, Ballybrit Business Park, Galway
Registered Office: Hewlett Packard Galway Ltd, 63-74 Sir John Rogerson's Quay,
D
On 10/07/14 15:05, Alexis Lee wrote:
> Tomas Sedovic said on Thu, Jul 10, 2014 at 02:26:06PM +0200:
>> On 09/07/14 17:52, Clint Byrum wrote:
>> +1 for both. However, some of the reviews show what I think is a
>> worrying trend in TripleO core. Specifically, nitpicking and tendency to
>> bikeshed.
>
I'd recommend adding this to the weekly Neutron ML2 meeting agenda [1]
and discussing it there. The ML2 sub-team leads (rkukura and Sukhdev)
are both at the Neutron mid-cycle meeting this week, so I'd suggest
next week's meeting.
Thanks!
Kyle
[1] https://wiki.openstack.org/wiki/Meetings/ML2
On W
On Wed, 2014-05-21 at 17:03 -0700, Devananda van der Veen wrote:
> I'd like to bring up the topic of drivers which, for one reason or
> another, are probably never going to have third party CI testing.
>
>
> Take for example the iBoot driver proposed here:
> https://review.openstack.org/50977
>
On Monday 07 July 2014 16:11:21 Joe Gordon wrote:
> On Jul 3, 2014 11:43 AM, "Dmitry Guryanov" wrote:
> > Hi, All!
> >
> > As far as I know, there are some requirements, which virt driver must
>
> meet to
>
> > use Openstack 'label'. For example, it's not allowed to mount cinder
>
> volumes
>
Hi Joe,
we know the Amazon's hot market is based on a economic model. Suppose to assign
to each group a virtual money amount for renting hot instances.
So, the money may reflect the "share" concept in our model. This means that a
big money amount may rent potentially more resources (actually it
On Thu, Jul 10, 2014 at 05:36:59PM +0400, Dmitry Guryanov wrote:
> I have a question about mounts - in OpenVZ project each container has its own
> filesystem in an image file. So to start a container we mount this filesystem
> in host OS (because all containers share the same linux kernel). Is it
On 07/10/2014 05:06 AM, Sylvain Bauza wrote:
> Hi all,
>
> ===
> tl;dr: Now that we agree on waiting for the split prereqs to be done, we
> debate on if ResourceTracker should be part of the scheduler code and
> consequently Scheduler should expose ResourceTracker APIs so that Nova
> wouldn't own
On Thu, Jul 10, 2014 at 08:37:40AM -0400, Eoghan Glynn wrote:
>
> > > Note that the notifications that capture these resource state transitions
> > > are a long-standing mechanism in openstack that ceilometer has depended
> > > on from the very outset. I don't think it's realistic to envisage thes
On Monday 07 July 2014 16:11:21 Joe Gordon wrote:
> On Jul 3, 2014 11:43 AM, "Dmitry Guryanov" wrote:
> > Hi, All!
> >
> > As far as I know, there are some requirements, which virt driver must
>
> meet to
>
> > use Openstack 'label'. For example, it's not allowed to mount cinder
>
> volumes
>
On Wed, Jul 09, 2014 at 09:16:01AM -0400, Sean Dague wrote:
> I think we need to actually step back a little and figure out where we
> are, how we got here, and what the future of validation might need to
> look like in OpenStack. Because I think there has been some
> communication gaps. (Also, for
Jay S. Bryant said on Wed, Jul 09, 2014 at 10:28:00PM -0500:
> > single quote: LOG.info("The ID '%s' is not invalid." % (resource.id))
> +1 This isn't one I have been policing a lot in my reviews, but think
> this is a good practice.
+1 from me.
> > LOG.info("This path is invalid: %s" % (obj.pat
On 7/10/2014 3:48 AM, Eoghan Glynn wrote:
TL;DR: do we need to stabilize notifications behind a versioned
and discoverable contract?
Folks,
One of the issues that has been raised in the recent discussions with
the QA team about branchless Tempest relates to some legacy defects
in the
On Tuesday 08 July 2014 14:10:25 Michael Still wrote:
> Joe has a good answer, but you should also be aware of the hypervisor
> support matrix (https://wiki.openstack.org/wiki/HypervisorSupportMatrix),
> which hopefully comes some way to explaining what we expect of a nova
> driver.
I've seen this
Hi Lisa,
Le 10/07/2014 15:40, Lisa a écrit :
> Hi Joe,
>
> we know the Amazon's hot market is based on a economic model. Suppose to
> assign to each group a virtual money amount for renting hot instances.
> So, the money may reflect the "share" concept in our model. This means that a
> big money
On Thu, Jul 10, 2014 at 05:57:46PM +0400, Dmitry Guryanov wrote:
> On Tuesday 08 July 2014 14:10:25 Michael Still wrote:
> > Joe has a good answer, but you should also be aware of the hypervisor
> > support matrix (https://wiki.openstack.org/wiki/HypervisorSupportMatrix),
> > which hopefully comes
On Thursday 10 July 2014 14:47:11 Daniel P. Berrange wrote:
> On Thu, Jul 10, 2014 at 05:36:59PM +0400, Dmitry Guryanov wrote:
> > I have a question about mounts - in OpenVZ project each container has its
> > own filesystem in an image file. So to start a container we mount this
> > filesystem in h
On 10/07/14 05:34, Steven Hardy wrote:
> >The other approach is to set up a new container, owned by the user, every
time. In that case, a provider selecting this implementation would need to make it
clear to customers if they would be billed for a WaitCondition resource. I'd prefer
to avoid th
On Thu, Jul 10, 2014 at 06:18:52PM +0400, Dmitry Guryanov wrote:
> On Thursday 10 July 2014 14:47:11 Daniel P. Berrange wrote:
> > On Thu, Jul 10, 2014 at 05:36:59PM +0400, Dmitry Guryanov wrote:
> > > I have a question about mounts - in OpenVZ project each container has its
> > > own filesystem in
On 7/10/2014 5:52 AM, Eoghan Glynn wrote:
> TL;DR: do we need to stabilize notifications behind a versioned
>and discoverable contract?
Thanks for dusting this off. Versioning and published schemas for
notifications are important to the StackTach team. It would be nice to
get this resolve
Active discussion at the gantt meeting this week, check out the log:
http://eavesdrop.openstack.org/meetings/gantt/2014/gantt.2014-07-01-15.00.log.html
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786
-Original Message-
From: Russell Bryant [mai
Hi!
There is a lot of useful information in that post (even excluding the
part brainstorming solutions) and it would be a shame if it was lost in
a sub-thread. Do you plan to make a blog post, or reference wiki page,
out of this ?
Back to the content, I think a more layered testing approach (as
s
On 07/10/2014 08:53 AM, Matthew Treinish wrote:
On Thu, Jul 10, 2014 at 08:37:40AM -0400, Eoghan Glynn wrote:
Note that the notifications that capture these resource state transitions
are a long-standing mechanism in openstack that ceilometer has depended
on from the very outset. I don't think i
On Thu, 10 Jul 2014, Julien Danjou wrote:
My initial plan was to leverage a library like voluptuous to do schema
based validation on the sender side. That would allow for receiver to
introspect schema and know the data structure to expect. I didn't think
deeply on how to handle versioning, but t
Le 10/07/2014 16:32, Dugger, Donald D a écrit :
> Active discussion at the gantt meeting this week, check out the log:
>
>
> http://eavesdrop.openstack.org/meetings/gantt/2014/gantt.2014-07-01-15.00.log.html
I would prefer to mention this week's meeting :
http://eavesdrop.openstack.org/mee
On 07/10/2014 09:47 AM, Thierry Carrez wrote:
Hi!
There is a lot of useful information in that post (even excluding the
part brainstorming solutions) and it would be a shame if it was lost in
a sub-thread. Do you plan to make a blog post, or reference wiki page,
out of this ?
Back to the conten
On Thu, 2014-07-10 at 14:47 +0100, Daniel P. Berrange wrote:
> On Thu, Jul 10, 2014 at 05:36:59PM +0400, Dmitry Guryanov wrote:
> > I have a question about mounts - in OpenVZ project each container has its
> > own
> > filesystem in an image file. So to start a container we mount this
> > filesys
Hi,
Thanks for Your answers.
Yep using binding:vif_details makes more sense. We would like to reuse
VIF_TYPE_OVS and modify the nova to use the userspace vhost when ‘use_dpdk’
flag is present.
What we are missing is how to inform the ml2 plugin/mechanism drivers when to
put that ‘use_dpdk’ fla
Excerpts from Victor Stinner's message of 2014-07-10 05:57:38 -0700:
> Le jeudi 10 juillet 2014, 14:48:04 Yuriy Taraday a écrit :
> > I'm not suggesting that taskflow is useless and asyncio is better (apple vs
> > oranges). I'm saying that using coroutines (asyncio) can improve ways we
> > can use
Hi Raildo,
Yes, I am trying to separate out the resource federation concerns through
Alliance, Identity federation will be intact with Keystone. At the same time
Alliance will play as delegate for keystone wherever resource federation across
clouds concern need to be addressed.
I would love to
Hi Matt,
It is not about identity federation (which is handled in Keystone), this is
about resource federation across clouds, Nova resources are one of them.
I don't know much about Nova cells right now, I will try to understand it soon.
Thanks,
Arvind
-Original Message-
From: Matt
Per the IRC discussion this morning, I believe it was decided that we would
prioritize creating a v2 agent which should run in parallel with the v1
agent. Further, for any subsequent driver shim layer, this should happen
after the v2 agent is functional.
... or I may have misunderstood what was de
Great,
I added this subject to next meetings agenda.
Regards
Przemek
-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com]
Sent: Thursday, July 10, 2014 2:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Mooney, Sean K
Subject: Re: [openstac
On Thu, Jul 10, 2014 at 08:19:36AM -0700, James Bottomley wrote:
> On Thu, 2014-07-10 at 14:47 +0100, Daniel P. Berrange wrote:
> > On Thu, Jul 10, 2014 at 05:36:59PM +0400, Dmitry Guryanov wrote:
> > > I have a question about mounts - in OpenVZ project each container has its
> > > own
> > > file
On 07/10/2014 08:08 AM, Frittoli, Andrea (HP Cloud) wrote:
++
The ugly monkey patch approach is still working fine for my downstream
testing, but that's something I'd be happy to get rid of.
Something that may be worth considering is to have an abstraction layer on top
of tempest clients, to al
On Thu, Jul 10, 2014 at 4:30 AM, shihanzhang wrote:
>
> With the deployment 'nova + neutron + openvswitch', when we bulk create
> about 500 VM with a default security group, the CPU usage of neutron-server
> and openvswitch agent is very high, especially the CPU usage of openvswitch
> agent will b
I blame MicroSoft, cut/paste didn't work so I had to manually type in the
(wrong) URL.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786
-Original Message-
From: Sylvain Bauza [mailto:sba...@redhat.com]
Sent: Thursday, July 10, 2014 9:05 AM
To: openstack-
Hi
tox.ini has the line # The rest of the ignores are TODOs
How serious are we about getting rid of these ignores?
Is it valid to -1 a patch that does not pass an ignored rule? E.g. E121
indentation is not a multiple of four
If a patch is submitted that does not pass a currently ignored rule, t
Currently we create a rescue instance by creating a new VM with the
original instance's image, then adding the original instance's first
disk to it, and booting. This means we have 2 VMs, which we need to be
careful of when cleaning up. Also when suspending, and probably other
edge cases. We also d
On 07/10/2014 09:48 AM, Matthew Treinish wrote:
> On Wed, Jul 09, 2014 at 09:16:01AM -0400, Sean Dague wrote:
>> I think we need to actually step back a little and figure out where we
>> are, how we got here, and what the future of validation might need to
>> look like in OpenStack. Because I think
On 7/9/14, 4:51 PM, Matt Riedemann wrote:
>
>
> On 6/12/2014 6:17 AM, Daniel P. Berrange wrote:
>> On Thu, Jun 12, 2014 at 07:07:37AM -0400, Sean Dague wrote:
>>> On 06/12/2014 06:59 AM, Daniel P. Berrange wrote:
Does anyone have any tip on how to actually run individual tests in an
effi
On Thu, 10 Jul 2014, Mike Bayer wrote:
I typically never use tox or testtools at the commandline until I'm
ready to commit and want to see what the jenkins builds will see. I
start up the whole thing and then it's time to take a break while it
reinvents the whole world.
Me tool I've been squ
Le 10/07/2014 15:47, Russell Bryant a écrit :
> On 07/10/2014 05:06 AM, Sylvain Bauza wrote:
>> Hi all,
>>
>> ===
>> tl;dr: Now that we agree on waiting for the split prereqs to be done, we
>> debate on if ResourceTracker should be part of the scheduler code and
>> consequently Scheduler should exp
Nice idea.
I say Œship it¹
The code was legacy and we just made sure it worked. Nice proposal
On 7/10/14, 6:52 PM, "Matthew Booth" wrote:
>Currently we create a rescue instance by creating a new VM with the
>original instance's image, then adding the original instance's first
>disk to it, and bo
On 2014-07-08 20:31:26 -0600 (-0600), Brian Jarrett wrote:
[...]
> Are there any projects that could use more developers?
[...]
That's a more complex question than you might think. On the whole
OpenStack does not need more developers writing new features. What
we *are* in desperate need of is deve
On 7/10/14, 7:47 AM, Sean Dague wrote:
> Honestly, that seems weird to me.
>
> oslo.db is built as a common layer for OpenStack services.
>
> eventlet is used by most OpenStack services.
>
> There are lots of known issues with eventlet vs. our db access patterns.
>
> Knowing that the db layer work
Thank Matt and Trevor,
Sorry everybody! Because i begin to learning+alone. So, difficulty in check
log and fix error.
matt <-- I receive error when create some node group templates for the
master and worker nodes. Then, i install sahara UI and already running
test. Thank you very much!
Best,
DC
On 07/10/2014 11:46 AM, Moore, Ryan wrote:
> Hi
>
>
>
> tox.ini has the line # The rest of the ignores are TODOs
>
> How serious are we about getting rid of these ignores?
>
>
>
> Is it valid to -1 a patch that does not pass an ignored rule? E.g. E121
> indentation is not a multiple of fou
Hi Arvind,
Now it's clear to me.
It will be a pleasure for me and my team help you. I'll be awaiting to see
the POC.
Regards,
2014-07-10 12:36 GMT-03:00 Tiwari, Arvind :
> Hi Matt,
>
> It is not about identity federation (which is handled in Keystone), this
> is about resource federation acro
Jeremy Stanley wrote:
> On 2014-07-08 20:31:26 -0600 (-0600), Brian Jarrett wrote:
> [...]
>> Are there any projects that could use more developers?
> [...]
>
> That's a more complex question than you might think. On the whole
> OpenStack does not need more developers writing new features. What
>
On 7/10/14, 12:08 PM, Chris Dent wrote:
> On Thu, 10 Jul 2014, Mike Bayer wrote:
>
>> I typically never use tox or testtools at the commandline until I'm
>> ready to commit and want to see what the jenkins builds will see. I
>> start up the whole thing and then it's time to take a break while it
This is also my understanding.
From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Thursday, July 10, 2014 6:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Shim vs Agent Refactor
Per the IRC discussion this morning, I
On Thu, Jul 10, 2014 at 7:13 PM, Jeremy Stanley wrote:
> On 2014-07-08 20:31:26 -0600 (-0600), Brian Jarrett wrote:
> [...]
> > Are there any projects that could use more developers?
> [...]
>
> That's a more complex question than you might think. On the whole
> OpenStack does not need more devel
On Thu, 2014-07-03 at 16:27 +0100, Mark McLoughlin wrote:
> Hey
>
> This is an attempt to summarize a really useful discussion that Victor,
> Flavio and I have been having today. At the bottom are some background
> links - basically what I have open in my browser right now thinking
> through all o
On Mon, 2014-07-07 at 12:48 +0200, Nikola Đipanov wrote:
> When I read all of this stuff and got my head around it (took some time
> :) ), a glaring drawback of such an approach, and as I mentioned on the
> spec proposing it [1] is that we would not really doing asyncio, we
> would just be pretend
Hi Everyone,
I would like to nominate Ade Lee for the barbican-core team.
Ade has been involved in the development of Barbican since January of this
year, and he’s been driving the work to enable DogTag to be used as a back
end for Barbican. Ade’s input to the design of barbican has been
invalua
1 - 100 of 165 matches
Mail list logo
