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 was
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 nex
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 1
[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 Javascri
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,
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
produ
Solly Ross 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 that line from the
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 example:
> 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
FWIW I'm very much in favour of having a single host API - I was
looking at doing that in Apache for TripleO deployments anyway, due to
the better SSL deployment characteristics. We then would register the
actual single host endpoint in publicURL.
How would that work for multiple regions with java
> I think we should not count bugs for HCF criteria if they affect only
> experimental feature(s).
+1, I'm totally agree with you - it makes no sense to count
experimental bugs as HCF criteria.
> Any objections / other ideas?
I think it would be great for customers if we point somewhere about
kn
+1 from me.
Best Regards,
Lianhao
> -Original Message-
> From: Julien Danjou [mailto:[email protected]]
> Sent: Wednesday, September 10, 2014 6:35 PM
> To: [email protected]
> Subject: [openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core
>
> Hi,
>
> Nejc ha
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 fai
+1
--
Mehdi Abaakouk
mail: [email protected]
irc: sileht
signature.asc
Description: Digital signature
___
OpenStack-dev mailing list
[email protected]
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
wrote
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 pe
> 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.
A
On Thu, Sep 11, 2014 at 09:23:34AM +1000, Michael Still wrote:
> On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes 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
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 t
On Wed, Sep 10, 2014 at 12:41:44PM -0700, Vishvananda Ishaya wrote:
>
> On Sep 5, 2014, at 4:12 AM, Sean Dague 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 mayb
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 the
On Thu, Sep 04, 2014 at 05:27:06PM +, Alessandro Pilotti wrote:
> This means that if we reach a point in which we agree to spin off the drivers
> in
> separate core projects, we need to consider how driver related CIs will be
> still
> included in the Nova review process, possibly with voting
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 Ol
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 f
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
Please also note, that all open patches created *before* the stable/5.1 branch
should now be reconsidered as targeted to 6.0 release instead of 5.1 as they
initially were upon the submission.
Therefore, all backporting stuff needed should be not forgotten and related
bugs should be updated as
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" 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, reply wi
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 th
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 first
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 use
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 certificat
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
> 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 e
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 wrote:
>>
>>> a) Sorting out the common code is already accounted for in Dan B's original
>>> proposal -- it's a prerequisite for the spl
On 09/10/2014 08:46 PM, Jamie Lennox wrote:
>
> - Original Message -
>> From: "Steven Hardy"
>> To: "OpenStack Development Mailing List (not for usage questions)"
>>
>> Sent: Thursday, September 11, 2014 1:55:49 AM
>> Subject: Re: [openstack-dev] [all] [clients] [keystone] lack of retry
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 th
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 underesti
On 09/10/2014 06:32 PM, James E. Blair wrote:
> James Polley 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:
>
>
> https://review.openstack.org/#/projects/openstack/nova,dashboards/impor
Hi,
On Thu, Sep 11, 2014 at 1:03 PM, Sebastian Kalinowski <
[email protected]> 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 wi
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 will
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:
https://bugs.launchpad.net/glance/+bugs?field.searc
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
> c
> 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
wrote:
> Probably, even "experimenta
On 9/11/14, 2:55 PM, "Thierry Carrez" 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 will
>> pro
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 that
On 09/10/2014 07:23 PM, Michael Still wrote:
On Thu, Sep 11, 2014 at 8:11 AM, Jay Pipes 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 about a release
worth
On September 11, 2014 3:52:59 AM PDT, Lucas Alvares Gomes
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 DevStack
>with
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 python-me
+1
On Thu, Sep 11, 2014 at 5:05 PM, Anastasia Urlapova
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 severity.
>
> On Thu, S
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 wrote:
> Hi,
>
> In most cases for plugin developers or fuel users
I'm in :)
+1
On Thu, Sep 11, 2014 at 4:58 PM, gordon chung 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 ma
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 th
May I be the first :)? Big +1 from me. Thanks Dina!
On Thu, Sep 11, 2014 at 5:24 PM, Julien Danjou 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 very active in o
On 09/11/2014 09:09 AM, Gary Kotton wrote:
>
>
> On 9/11/14, 2:55 PM, "Thierry Carrez" 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" 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
On 11 September 2014 12:36, Sean Dague 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 bigger, and wit
On 11 Sep 2014, at 09:19, Mike Scherbakov 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 dev
> cycle, we c
On 11 September 2014 03:17, Angus Lees 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) failing if
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 stra
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
wrote:
>
> On 11 Sep 2014, at 09:19, Mike Scherbakov
> wrote:
>
> > Hi all,
>
On Wed, Sep 10, 2014 at 08:46:45PM -0400, Jamie Lennox wrote:
>
> - Original Message -
> > From: "Steven Hardy"
> > To: "OpenStack Development Mailing List (not for usage questions)"
> >
> > Sent: Thursday, September 11, 2014 1:55:49 AM
> > Subject: Re: [openstack-dev] [all] [clients] [
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 wrote:
> On 09/11/2014 04:30 PM, Sean Dague wrote:
>>
>> On 09/11/2014 09:09 AM, Gary Kotton 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 features should become experimental. We should have this
information in release notes.
Basically, Patching of O
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
>
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 router),
> 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 convi
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"
> To: "OpenStack Development Mailing List (not for usage q
On 9/11/14, 4:30 PM, "Sean Dague" wrote:
>On 09/11/2014 09:09 AM, Gary Kotton wrote:
>>
>>
>> On 9/11/14, 2:55 PM, "Thierry Carrez" 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
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
suppo
On 11 September 2014 15:35, James Bottomley
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 contributing team
> to a bunch of them. Th
Steven Hardy 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 related thin
On Thu, 2014-09-11 at 16:20 +0100, Duncan Thomas wrote:
> On 11 September 2014 15:35, James Bottomley
> 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
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+Meeting&iso=20140911T18
P.S. I'm on vacation this week, so, A
On 09/11/2014 12:50 AM, Jesse Pretorius wrote:
On 10 September 2014 17:20, Chris Friesen mailto:[email protected]>> wrote:
I see that the OpenStack high availability guide is still
recommending the active/standby method of configuring RabbitMQ.
Has anyone tried using activ
Hi,
+1 from me too, thanks for all the hard work so far.
Best Regards,
Ildikó
-Original Message-
From: Julien Danjou [mailto:[email protected]]
Sent: Thursday, September 11, 2014 3:25 PM
To: [email protected]
Subject: [openstack-dev] [Ceilometer] Adding Dina Belova to c
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 Wed
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 plu
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 :-( .
Un
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 every
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 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 guys to give
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).
S
On 09/11/2014 11:14 AM, Gary Kotton wrote:
>
>
> On 9/11/14, 4:30 PM, "Sean Dague" wrote:
>
>> On 09/11/2014 09:09 AM, Gary Kotton wrote:
>>>
>>>
>>> On 9/11/14, 2:55 PM, "Thierry Carrez" wrote:
>>>
Sean Dague wrote:
> [...]
> Why don't we start with "let's clean up the virt inter
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) t
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:
https://github.com/openstack/trove/commit/06196fcf67b27f0308381da192da5cc8ae65b157#diff-a4d09d28bd2b650c2327f5d8d81be3a9
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 t
On 10 September 2014 22:23, Russell Bryant 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 cycle or so.
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 painte
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 buil
On Wed, Sep 10, 2014 at 6:09 PM, Kurt Griffiths
wrote:
> On 9/10/14, 3:58 PM, "Devananda van der Veen"
> 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 hide anything about the setup.
> I thoug
QA-agree.
--
nurla
On Thu, Sep 11, 2014 at 6:28 PM, Mike Scherbakov
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 features should become ex
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, bu
1 - 100 of 135 matches
Mail list logo
