Fixed the issue and it's a boneheaded one as I suspected.
I need to initialize the type ala wtypes.IPv4AddressType() instead of
just wtypes.IPv4AddressType.
Does appear that the validation for the IPv4AddressType has a bug where
is should return the value, but there is no return at all.
Thanks,
On 09/10/2014 03:18 PM, Gordon Sim wrote:
On 09/10/2014 09:58 AM, Flavio Percoco wrote:
To clarify the doubts of what Zaqar is or it's not, let me quote what's
written in the project's overview section[0]:
Zaqar is a multi-tenant cloud messaging service for web developers.
How are
On 10 September 2014 17:20, Chris Friesen chris.frie...@windriver.com
wrote:
I see that the OpenStack high availability guide is still recommending the
active/standby method of configuring RabbitMQ.
Has anyone tried using active/active with mirrored queues as recommended
by the RabbitMQ
I want to apologize for my rapid response, I was incorrect about the license
because of the file you pointed out. I did not intend to sound snarky or
anything like that in either the original email or the reply.
Anyway, for future reference, I believe the last thread where this was
discussed
Le 11/09/2014 01:10, Joe Cropper a écrit :
Agreed - I’ll draft up a formal proposal in the next week or two and we can
focus the discussion there. Thanks for the feedback - this provides a good
framework for implementation considerations.
Count me on it, I'm interested in discussing the
Great to hear. I started a blueprint for this [1]. More detail can be added
once the kilo nova-specs directory is created… for now, I’ve tried to put some
fairly detailed notes on the blueprint’s description.
[1] https://blueprints.launchpad.net/nova/+spec/dynamic-server-groups
- Joe
On Sep
[This is Horizon-related but affects every service in OpenStack, hence no
filter in the subject]
I would like for OpenStack to support browser-based Javascript API clients.
Currently this is not possible because of cross-origin resource blocking in
Javascript clients - that is, given some
Hi Matt,
On 09/10/2014 04:30 AM, Matt Riedemann wrote:
It took me a while to untangle this so prepare for links. :)
I noticed this change [1] today for global-requirements to require tooz
[2] for a ceilometer blueprint [3].
The sad part is that tooz requires pymemcache [4] which is, from
Hi all,
what about using experimental tag for experimental features?
After we implemented feature groups [1], we can divide our features and for
complex features, or those which don't get enough QA resources in the dev
cycle, we can declare as experimental. It would mean that those are not
Solly Ross sr...@redhat.com writes:
Hi,
I recently began using using ESLint for all my JavaScript linting:
http://eslint.org/
It has nice documentation, a normal license, and you can easily write
new rules for it.
P.S. Here's hoping that the JSHint devs eventually find a way to
remove
Hi,
Here's a message from the maintainer of python-django in Debian. We've
been trying to switch to Django 1.7, because we would like to benefits
from its security support for the life of Debian Jessie.
I have already fixed numerous Debian packages regarding Django 1.7
compatibility (for
Hi,
Nejc has been doing a great work and has been very helpful during the
Juno cycle and his help is very valuable.
I'd like to propose that we add Nejc Saje to the ceilometer-core group.
Please, dear ceilometer-core members, reply with your votes!
A hearty +1 for me, Nejc has made a
On Wed, Sep 10, 2014 at 04:44:01PM -0500, Jason Greathouse wrote:
I'm trying to find a way to create a set of servers and attach a new
volume to each server.
I first tried to use block_device_mapping but that requires an existing
snapshot or volume and the deployment would fail
+1
--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht
signature.asc
Description: Digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
if we point somewhere about knowing issues in those experimental features
there are might be dozens of bugs.
May be we can use tag per feature, for example zabbix, so it will be easy
to search in LP all open bugs regarding Zabbix feature?
On Thu, Sep 11, 2014 at 12:11 PM, Igor Kalnitsky
Hi stackers,
According to my statistics(J2), the LOC of vendors' plugin and driver is
about 102K, while the whole under neutron is 220K.
That is to say the community has paid and is paying over 46% energy to
maintain vendors' code. If we take mails, bugs,
BPs and so on into consideration, this
May be we can use tag per feature, for example zabbix
Tags are ok, but I still think that we can mention at least some
significant bugs. For example, if some feature doesn't work in some
deployment mode (e.g. simple, with ceilometer, etc) we can at least
notify users so they even don't try.
On Thu, Sep 11, 2014 at 09:23:34AM +1000, Michael Still wrote:
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes jaypi...@gmail.com wrote:
a) Sorting out the common code is already accounted for in Dan B's original
proposal -- it's a prerequisite for the split.
Its a big prerequisite though. I
On Wed, Sep 10, 2014 at 07:35:05PM -0700, Armando M. wrote:
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing cycle or so.
Likely, this effort is going to take
On Wed, Sep 10, 2014 at 12:41:44PM -0700, Vishvananda Ishaya wrote:
On Sep 5, 2014, at 4:12 AM, Sean Dague s...@dague.net wrote:
On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
Just some things to think about with regards to the whole idea, by no
means exhaustive.
So maybe the
This has been brought up several times already and I believe is going to be
discussed at the Kilo summit.
I agree that reviewing third party patches eats community time. However,
claiming that the community pays 46% of it's energy to maintain
vendor-specific code doesn't make any sense. LOC in
Hi Lukasz,
Regarding to 'Node agent authorization' do you have some ideas how it could
be done?
For me it looks really complicated, because we don't upgrade agents on
slave nodes and
I'm not sure if we will be able to do it in the nearest future.
Thanks,
On Tue, Sep 9, 2014 at 1:50 PM, Lukasz
James E. Blair wrote:
[]
We write code in a terminal. We read logs in a terminal. We debug code
in a terminal. We commit in a terminal. You know what's next.
[]
Hello James,
thanks for the announce and for gertty, I am new to OpenStack, and
this tools is really interesting to me. In
Hi all,
I have been trying to deploy Openstack-ironic on a Ubuntu 12.04 VM.
I encountered the following error:
2014-09-11 10:08:11.166 | Reading package lists...
2014-09-11 10:08:11.471 | Building dependency tree...
2014-09-11 10:08:11.475 | Reading state information...
2014-09-11 10:08:11.610
Probably, even experimental feature should at least pretend to be
working, anyway, or it shouldn't be publically announced. But I think
it's important to describe limitation of this features (or mark some
of them as untested) and I think list of known issues with links to
most important bugs is a
Hi,
Just a reminder that the weekly Nova API meeting is being held tomorrow
Friday UTC .
We encourage cloud operators and those who use the REST API such as
SDK developers and others who and are interested in the future of the
API to participate.
In other timezones the meeting is at:
EST
I am trying to find out how traffic currently flows went sent to an
instance through a LB.
Say I have the following scenario:
RHA1 LB_A -- - LB_B --- RHB1
| |
RHA2 ---|
On 10/09/2014 8:37 PM, Julien Danjou jul...@danjou.info wrote:
Hi,
Nejc has been doing a great work and has been very helpful during the
Juno cycle and his help is very valuable.
I'd like to propose that we add Nejc Saje to the ceilometer-core group.
Please, dear ceilometer-core members,
Oh, it's because Precise doesn't have the docker.io package[1] (nor docker).
AFAIK the -infra team is now using Trusty in gate, so it won't be a
problem. But if you think that we should still support Ironic DevStack
with Precise please file a bug about it so the Ironic team can take a
look on
I have some topics for [1] that I want to discuss:
1) Should we allow users to turn SSL on/off for Fuel master?
I think we should since some users may don't care about SSL and
enabling it will just make them unhappy (like warnings in browsers,
expiring certs).
2) Will we allow users (in
On 09/10/2014 03:45 PM, Gordon Sim wrote:
On 09/10/2014 01:51 PM, Thierry Carrez wrote:
I think we do need, as Samuel puts it, some sort of durable
message-broker/queue-server thing. It's a basic application building
block. Some claim it's THE basic application building block, more useful
Hi,
We definitely need a person who will help with design for the feature.
Here is the list of open questions:
1. UI design for certificates uploading
2. CLI
3. diagnostic snapshot sanitising
4. REST API/DB design
5. background tasks for nailgun (?)
6. do we need separate container to
On 09/10/2014 06:11 PM, Jay Pipes wrote:
On 09/10/2014 05:55 PM, Chris Friesen wrote:
On 09/10/2014 02:44 AM, Daniel P. Berrange wrote:
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
I have the impression this idea has been circling around for a while
but
for some
As you all know, there has recently been several very active discussions
around how to improve assorted aspects of our development process. One idea
that was brought up is to come up with a list of cycle goals/project
priorities for Kilo [0].
To that end, I would like to propose an
On 09/11/2014 05:18 AM, Daniel P. Berrange wrote:
On Thu, Sep 11, 2014 at 09:23:34AM +1000, Michael Still wrote:
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes jaypi...@gmail.com wrote:
a) Sorting out the common code is already accounted for in Dan B's original
proposal -- it's a prerequisite for
On 09/10/2014 08:46 PM, Jamie Lennox wrote:
- Original Message -
From: Steven Hardy sha...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Thursday, September 11, 2014 1:55:49 AM
Subject: Re: [openstack-dev] [all]
On 09/10/2014 11:55 AM, Steven Hardy wrote:
On Wed, Sep 10, 2014 at 10:14:32AM -0400, Sean Dague wrote:
Going through the untriaged Nova bugs, and there are a few on a similar
pattern:
Nova operation in progress takes a while
Crosses keystone token expiration time
Timeout thrown
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think there is any disagreement there. If it's
going to take a cycle, it's going to take a cycle anyway (it will
probably take 2 cycles, realistically, we always underestimate
On 09/10/2014 06:32 PM, James E. Blair wrote:
James Polley j...@jamezpolley.com writes:
Incidentally, that is the query in the Wayward Changes section of the
Review Inbox dashboard (thanks Sean!); for nova, you can see it here:
Hi,
On Thu, Sep 11, 2014 at 1:03 PM, Sebastian Kalinowski
skalinow...@mirantis.com wrote:
I have some topics for [1] that I want to discuss:
1) Should we allow users to turn SSL on/off for Fuel master?
I think we should since some users may don't care about SSL and
enabling it will
Hi,
In most cases for plugin developers or fuel users it will be much
easier to just write command which he wants to run on nodes
instead of describing some abstract task which doesn't have
any additional information/logic and looks like unnecessary complexity.
But for complicated cases user
Hi folks,
you could subscribe to specs rss now -
http://specs.openstack.org/openstack/sahara-specs/rss
Thanks for the Doug Hellmann for implementing it.
--
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
Hi Folks!
Glance is having its bug triage day today! Please help out if you can.
You can check out the tasks here:
http://etherpad.openstack.org/p/glancebugday
Also here are some handy links to the untriaged bugs in glance and the
client:
On 09/11/2014 02:28 PM, Cindy Pallares wrote:
Hi Folks!
Glance is having its bug triage day today! Please help out if you can.
You can check out the tasks here:
http://etherpad.openstack.org/p/glancebugday
Also here are some handy links to the untriaged bugs in glance and the
client:
Nejc has been doing a great work and has been very helpful during the Juno
cycle and his help is very valuable.
I'd like to propose that we add Nejc Saje to the ceilometer-core group.can we
minus because he makes me look bad? /sarcasm
+1 for core.
cheers,
gord
I think we should not count bugs for HCF criteria if they affect only
experimental feature(s).
+1, absolutely agree, but we should determine count of allowed bugs for
experimental features against severity.
On Thu, Sep 11, 2014 at 2:13 PM, Nikolay Markov nmar...@mirantis.com
wrote:
Probably,
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think there is any disagreement there. If it's
going to take a cycle, it's going to take a cycle anyway (it
On 09/11/2014 07:32 AM, Eoghan Glynn wrote:
As you all know, there has recently been several very active discussions
around how to improve assorted aspects of our development process. One idea
that was brought up is to come up with a list of cycle goals/project
priorities for Kilo [0].
To
On 09/10/2014 07:23 PM, Michael Still wrote:
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes jaypi...@gmail.com wrote:
a) Sorting out the common code is already accounted for in Dan B's original
proposal -- it's a prerequisite for the split.
Its a big prerequisite though. I think we're talking
On September 11, 2014 3:52:59 AM PDT, Lucas Alvares Gomes
lucasago...@gmail.com wrote:
Oh, it's because Precise doesn't have the docker.io package[1] (nor
docker).
AFAIK the -infra team is now using Trusty in gate, so it won't be a
problem. But if you think that we should still support Ironic
On Tue, Sep 09 2014, Matt Riedemann wrote:
I noticed this change [1] today for global-requirements to require tooz [2]
for
a ceilometer blueprint [3].
The sad part is that tooz requires pymemcache [4] which is, from what I can
tell, a memcached client that is not the same as
+1
On Thu, Sep 11, 2014 at 5:05 PM, Anastasia Urlapova aurlap...@mirantis.com
wrote:
I think we should not count bugs for HCF criteria if they affect only
experimental feature(s).
+1, absolutely agree, but we should determine count of allowed bugs for
experimental features against
Let's not create architectural leaks here. Let there be only tasks, but
let's create a really simple template for task that user will be able to
easily fill only with the command itself.
On Thu, Sep 11, 2014 at 4:17 PM, Evgeniy L e...@mirantis.com wrote:
Hi,
In most cases for plugin
I'm in :)
+1
On Thu, Sep 11, 2014 at 4:58 PM, gordon chung g...@live.ca wrote:
Nejc has been doing a great work and has been very helpful during the
Juno cycle and his help is very valuable.
I'd like to propose that we add Nejc Saje to the ceilometer-core group.
can we minus because he
Hi,
Dina has been doing a great work and has been very helpful during the
Juno cycle and her help is very valuable. She's been doing a lot of
reviews and has been very active in our community.
I'd like to propose that we add Dina Belova to the ceilometer-core
group, as I'm convinced it'll help
May I be the first :)? Big +1 from me. Thanks Dina!
On Thu, Sep 11, 2014 at 5:24 PM, Julien Danjou jul...@danjou.info wrote:
Hi,
Dina has been doing a great work and has been very helpful during the
Juno cycle and her help is very valuable. She's been doing a lot of
reviews and has been
On 09/11/2014 09:09 AM, Gary Kotton wrote:
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think there is any disagreement there. If it's
going to take a
+1, absolutely agree, but we should determine count of allowed bugs for
experimental features against severity.
Anastasia, can you please give an example? I think we should not count them
at all. Experimental features, if they are isolated, they can be in any
stated. May be just very beginning of
On 09/11/2014 04:30 PM, Sean Dague wrote:
On 09/11/2014 09:09 AM, Gary Kotton wrote:
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think there is any
On 11 September 2014 12:36, Sean Dague s...@dague.net wrote:
I continue to not understand how N non overlapping teams makes this any
better. You have to pay the integration cost somewhere. Right now we're
trying to pay it 1 patch at a time. This model means the integration
units get much
On 11 Sep 2014, at 09:19, Mike Scherbakov mscherba...@mirantis.com wrote:
Hi all,
what about using experimental tag for experimental features?
After we implemented feature groups [1], we can divide our features and for
complex features, or those which don't get enough QA resources in the
On 11 September 2014 03:17, Angus Lees g...@inodes.org wrote:
(As inspired by eg kerberos)
2. Ensure at some environmental/top layer that the advertised token lifetime
exceeds the timeout set on the request, before making the request. This
implies (since there's no special handling in place)
Hello everyone!
I'm working on implementing test in Neutron that checks that models are
synchronized with database state [1] [2]. This is very important change as
during Juno cycle big changes of database structure were done.
I was working on it for rather long time but about three weeks ago
Mike, i've just want to say, if feature isn't ready for production use and
we have no other choice, we should provide detailed limitations and
examples of proper use.
On Thu, Sep 11, 2014 at 5:58 PM, Tomasz Napierala tnapier...@mirantis.com
wrote:
On 11 Sep 2014, at 09:19, Mike Scherbakov
On Wed, Sep 10, 2014 at 08:46:45PM -0400, Jamie Lennox wrote:
- Original Message -
From: Steven Hardy sha...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Thursday, September 11, 2014 1:55:49 AM
Subject:
Rados,
personally, i'd want a human to do the +W. Also the critieria would
include a 3) which is the CI for the driver if applicable.
On Thu, Sep 11, 2014 at 9:53 AM, Radoslav Gerganov rgerga...@vmware.com wrote:
On 09/11/2014 04:30 PM, Sean Dague wrote:
On 09/11/2014 09:09 AM, Gary Kotton
Mike, i've just want to say, if feature isn't ready for production use
and we have no other choice, we should provide detailed limitations and
examples of proper use.
Fully agree, such features should become experimental. We should have this
information in release notes.
Basically, Patching of
On Thu, 2014-09-11 at 07:36 -0400, Sean Dague wrote:
b) The conflict Dan is speaking of is around the current situation where
we
have a limited core review team bandwidth and we have to pick and choose
which virt driver-specific features we will review. This leads to bad
feelings and
On 9/10/14, 6:54 PM, Kevin Benton wrote:
Being in the incubator won't help with this if it's a different repo
as well.
Agreed.
Given the requirement for GBP to intercept API requests, the potential
couplings between policy drivers, ML2 mechanism drivers, and even
service plugins (L3
Hi,
Dina has been doing a great work and has been very helpful during the
Juno cycle and her help is very valuable. She's been doing a lot of
reviews and has been very active in our community.
I'd like to propose that we add Dina Belova to the ceilometer-core
group, as I'm convinced
My mistake about the mailing list, The openstack heat wiki page (
https://wiki.openstack.org/wiki/Heat) only lists the dev list. I will
make sure to ask future usage questions on the other one.
Thank you for the response and example. This is what I was missing.
On Thu, Sep 11, 2014 at 3:21 AM,
Thanks! ESLint looks interesting. I'm curious to see what it
says about the Horizon source. I'll keep it in mind for future
personal projects and the like.
Best Regards,
Solly Ross
- Original Message -
From: Martin Geisler mar...@geisler.net
To: OpenStack Development Mailing List
On 9/11/14, 4:30 PM, Sean Dague s...@dague.net wrote:
On 09/11/2014 09:09 AM, Gary Kotton wrote:
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt interface and make it
more sane, as I don't think
On 2014-09-11 01:27:23 -0400 (-0400), Russell Bryant wrote:
[...]
But seriously, we should probably put out a more official notice about
this once Kilo opens up.
It's probably worth carrying in the release notes for all Juno
servers... This is the last release of OpenStack with official
support
On 11 September 2014 15:35, James Bottomley
james.bottom...@hansenpartnership.com wrote:
OK, so look at a concrete example: in 2002, the Linux kernel went with
bitkeeper precisely because we'd reached the scaling limit of a single
integration point, so we took the kernel from a single
Steven Hardy sha...@redhat.com wrote on 09/11/2014 04:21:18 AM:
On Wed, Sep 10, 2014 at 04:44:01PM -0500, Jason Greathouse wrote:
I'm trying to find a way to create a set of servers and attach a
new
volume to each server.
...
Basically creating lots of resource groups for
On Thu, 2014-09-11 at 16:20 +0100, Duncan Thomas wrote:
On 11 September 2014 15:35, James Bottomley
james.bottom...@hansenpartnership.com wrote:
OK, so look at a concrete example: in 2002, the Linux kernel went with
bitkeeper precisely because we'd reached the scaling limit of a single
On Thu, Sep 11, 2014 at 10:06:01AM -0500, Jason Greathouse wrote:
My mistake about the mailing list, The openstack heat wiki page
(https://wiki.openstack.org/wiki/Heat) only lists the dev list. I will
make sure to ask future usage questions on the other one.
No worries, we should
Hi folks,
We'll be having the Sahara team meeting as usual in
#openstack-meeting-alt channel.
Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20140911T18
P.S. I'm on vacation this week, so,
On 09/11/2014 12:50 AM, Jesse Pretorius wrote:
On 10 September 2014 17:20, Chris Friesen chris.frie...@windriver.com
mailto:chris.frie...@windriver.com wrote:
I see that the OpenStack high availability guide is still
recommending the active/standby method of configuring RabbitMQ.
Hi,
+1 from me too, thanks for all the hard work so far.
Best Regards,
Ildikó
-Original Message-
From: Julien Danjou [mailto:jul...@danjou.info]
Sent: Thursday, September 11, 2014 3:25 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Ceilometer] Adding Dina Belova to
Yes, not sure why the HA guide says that.
Only problems I've run into was around cluster upgrades. If you're running
3.2+ you'll likely have a better experience.
List ha_queues in all your configs, list all your rabbit hosts (I don't use
a VIP as heartbeats weren't working when I did this)
On
Hi All,
I'm hoping to get this blueprint
https://blueprints.launchpad.net/neutron/+spec/dhcp-options-per-subnet
some love...seems it's been hanging around since January so my
assumption is it's not going anywhere.
As a private cloud operator I make heavy use of vlan based provider
networks to
Thanks. This is good writeup.
Of course this all assumes there is consensus that we should proceed with
GBP, that we should continue by iterating the currently proposed design and
code, and that GBP should eventually become part of Neutron. These
assumptions may still be the real issues :-( .
On 19:32 Fri 05 Sep , David Pineau wrote:
So I asked Duncan what could be done, learned about the FFE, and I am
now humbly asking you guys to give us a last chance to get in for
Juno. I was told that if it was possible the last delay would be next
week, and believe me, we're doing
On 12:23 Tue 09 Sep , yunling wrote:
Hi Cinder Folks,I would like to request a FFE for add reset-state function
for backups[1][2].The spec of add reset-state function for backups has been
reviewed and merged[2]. These code changes have been well tested and are not
very complex[3]. I
Mike
This FFE request was withdraw. I updated the etherpad but didn't mail
the list, sorry
On 11 September 2014 18:07, Mike Perez thin...@gmail.com wrote:
On 19:32 Fri 05 Sep , David Pineau wrote:
So I asked Duncan what could be done, learned about the FFE, and I am
now humbly asking you
I agree with Kevin. Any option in-tree or in-incubator would need core
review time, and they are already oversubscribed with nova parity issues
(for Juno). So the only option to continue collaboration on experimenting
with policy based networking on current openstack is on stackforge (option
5).
On 09/11/2014 11:14 AM, Gary Kotton wrote:
On 9/11/14, 4:30 PM, Sean Dague s...@dague.net wrote:
On 09/11/2014 09:09 AM, Gary Kotton wrote:
On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote:
Sean Dague wrote:
[...]
Why don't we start with let's clean up the virt
I agree with Kevin. Like in Juno, we as a subteam will be shooting for
option 1 (again) for Kilo - ideally we can land in Kilo, and we will work
closely with the community to try to accomplish that. In the meantime, we
need to have a repo to iterate our implementations, build package (Juno
based)
Hi everyone,
I was looking through the clustering code today and noticed a lot of it is
grabbing what I'd call the guts of the instance models code.
The best example is here:
On Thu, 2014-09-04 at 11:24 +0100, Daniel P. Berrange wrote:
Position statement
==
Over the past year I've increasingly come to the conclusion that
Nova is heading for (or probably already at) a major crisis. If
steps are not taken to avert this, the project is likely to
On 10 September 2014 22:23, Russell Bryant rbry...@redhat.com wrote:
On 09/10/2014 10:35 PM, Armando M. wrote:
Hi,
I devoured this thread, so much it was interesting and full of
insights. It's not news that we've been pondering about this in the
Neutron project for the past and existing
On 09/11/2014 12:02 PM, Dan Prince wrote:
Maybe I'm impatient (I totally am!) but I see much of the review
slowdown as a result of the feedback loop times increasing over the
years. OpenStack has some really great CI and testing but I think our
focus on not breaking things actually has us
Excerpts from Flavio Percoco's message of 2014-09-11 04:14:30 -0700:
On 09/10/2014 03:45 PM, Gordon Sim wrote:
On 09/10/2014 01:51 PM, Thierry Carrez wrote:
I think we do need, as Samuel puts it, some sort of durable
message-broker/queue-server thing. It's a basic application building
On Wed, Sep 10, 2014 at 6:09 PM, Kurt Griffiths
kurt.griffi...@rackspace.com wrote:
On 9/10/14, 3:58 PM, Devananda van der Veen devananda@gmail.com
wrote:
I'm going to assume that, for these benchmarks, you configured all the
services optimally.
Sorry for any confusion; I am not trying to
QA-agree.
--
nurla
On Thu, Sep 11, 2014 at 6:28 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Mike, i've just want to say, if feature isn't ready for production use
and we have no other choice, we should provide detailed limitations and
examples of proper use.
Fully agree, such
Mike,
2 jobs for Icehouse and Juno equal 2 different repository with packages for
Fuel 6.0. This can be problem for current osci workflow.
For example: We need building new packages. Which repository we must put
packages? to icehouse or/and Juno ?
if new packages will break icehouse repository,
So we had a Bug Day this week and the results were a bit disappointing
due to lack of participation. We went from 124 New bugs to 75. There
were also many cases where bugs referred to logs that no longer existed.
This suggests that we really need to keep up with bug triage in real
time. Since
On 04/09/14 08:14, Sean Dague wrote:
I've been one of the consistent voices concerned about a hard
requirement on adding NoSQL into the mix. So I'll explain that thinking
a bit more.
I feel like when the TC makes an integration decision previously this
has been about evaluating the project
1 - 100 of 126 matches
Mail list logo
