> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Tuesday, September 09, 2014 4:29 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] Kilo Cycle Goals Exercise
>
> > 3. Another long-term topic is standardizing our APIs so that we use
> > con
I needs to point at a devstack or openstack installation for login to work.
On 12 September 2014 15:50, Rajdeep Dua wrote:
> Hi,
> I have setup a local dev environment with a custom dashboard using
> instructions below
>
> http://docs.openstack.org/developer/horizon/topics/tutorial.html
>
> Hori
Hi,
I have setup a local dev environment with a custom dashboard using
instructions below
http://docs.openstack.org/developer/horizon/topics/tutorial.html
Horizon started using ./run_tests.sh --runserver 0.0.0.0:8877
What is the default password for admin login?
Note : it is not pointing to any
> Maybe I missed something, but what's the solution?
There isn't one yet. That's why it's going to be discussed at the summit.
> I think we should release a workable version.
Definitely. But that doesn't have anything to do with it living in the same
repository. By putting it in a different repo
Some comments inline.
BR,
Germy
On Thu, Sep 11, 2014 at 5:47 PM, Kevin Benton wrote:
> This has been brought up several times already and I believe is going to
> be discussed at the Kilo summit.
>
Maybe I missed something, but what's the solution?
> I agree that reviewing third party patches
On 12 September 2014 09:24, Richard Jones wrote:
> On 12 September 2014 07:50, Adam Young wrote:
>
>> So, lets have these two approaches work in parallel. THe proxy will get
>> things goint while we work out the CORS approach.
>>
>
> I will look at submitting my middleware for inclusion anyway
Excerpts from Zane Bitter's message of 2014-09-11 15:21:26 -0700:
> On 09/09/14 19:56, Clint Byrum wrote:
> > Excerpts from Samuel Merritt's message of 2014-09-09 16:12:09 -0700:
> >> On 9/9/14, 12:03 PM, Monty Taylor wrote:
> >>> On 09/04/2014 01:30 AM, Clint Byrum wrote:
> Excerpts from Flav
Definitely +1 from me
Lianhao
> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Thursday, September 11, 2014 9:25 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core
>
> Hi,
>
> Dina has be
- Original Message -
> From: "Travis S Tripp"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Friday, 12 September, 2014 10:30:53 AM
> Subject: [openstack-dev] masking X-Auth-Token in debug output - proposed
> consistency
>
>
>
> Hi All,
>
>
>
> I’
Hi Travis,
By and large we have addressed this in the Session code within Keystoneclient
via the function here (and other similar cases):
https://github.com/openstack/python-keystoneclient/blob/01cabf6bbbee8b5340295f3be5e1fa7111387e7d/keystoneclient/session.py#L126-L131
If/when Glanceclient is
- Original Message -
> From: "Steven Hardy"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Friday, 12 September, 2014 12:21:52 AM
> Subject: Re: [openstack-dev] [all] [clients] [keystone] lack of retrying
> tokens leads to overall OpenStack fragility
>
Hi All,
I'm just helping with bug triage in Glance and we've got a bug to update how
tokens are redacted in the glanceclient [1]. It says to update to whatever
cross-project approach is agreed upon and references this thread:
http://lists.openstack.org/pipermail/openstack-dev/2014-June/037345.
- Original Message -
> From: "Sean Dague"
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, 11 September, 2014 9:44:43 PM
> Subject: Re: [openstack-dev] [all] [clients] [keystone] lack of retrying
> tokens leads to overall OpenStack fragility
>
> On 09/10/2014 08:46 PM, Jamie L
Kurt,
Speaking generally, I’d like to see the project bake this in over time as
> part of the CI process. It’s definitely useful information not just for
> the developers but also for operators in terms of capacity planning. We’ve
>
talked as a team about doing this with Rally (and in fact, some
On Sep 11, 2014, at 5:05 PM, Kevin L. Mitchell
wrote:
> I'd suggest trying:
>
>res = amodel.Assemblies(
>uri=common.ASSEM_URI_STR % pecan.request.host_url,
>name='Solum_CAMP_assemblies',
>type='assemblies',
>description=common.ASSEM_DESC_S
We manage a fairly large nova-baremetal installation at Yahoo. And while we've
developed tools to hit the nova-bm API, we're planning to move to ironic
without any support for the nova BM API. Definitely no interest in the proxy
API from our end.
Sometimes you just need to let a thing die.
-Ja
On 11 September 2014 18:00, Robert Collins
wrote:
> 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 pu
On 12 September 2014 07:50, Adam Young wrote:
> On 09/11/2014 03:15 AM, Richard Jones wrote:
>
> [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
On 9/11/14, 2:11 PM, "Devananda van der Veen"
wrote:
>OK - those resource usages sound better. At least you generated enough
>load to saturate the uWSGI process CPU, which is a good point to look
>at performance of the system.
>
>At that peak, what was the:
>- average msgs/sec
>- min/max/avg/stde
It isn't a huge change. I am ok with it if we can get the issues
addressed. Especially Duncan's concern.
On Sep 11, 2014 12:17 PM, "Mike Perez" wrote:
> 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].
On 09/11/2014 04:09 PM, Zane Bitter wrote:
Swift is the current exception here, but one could argue, and people
have[2], that Swift is also the only project that actually conforms to
our stated design tenets for OpenStack. I'd struggle to tell the Zaqar
folks they've done the Wrong Thing... espec
On 09/11/2014 04:22 PM, Joe Cropper wrote:
I would be a little wary about the DB level locking for stuff like that
— it’s certainly doable, but also comes at the expense of things
behaving ever-so-slightly different from DBMS to DBMS. Perhaps there
are multiple “logical efforts” here—i.e., addin
I would be a little wary about the DB level locking for stuff like that — it’s
certainly doable, but also comes at the expense of things behaving
ever-so-slightly different from DBMS to DBMS. Perhaps there are multiple
“logical efforts” here—i.e., adding some APIs and cleaning up existing code.
On 09/09/14 19:56, Clint Byrum wrote:
Excerpts from Samuel Merritt's message of 2014-09-09 16:12:09 -0700:
On 9/9/14, 12:03 PM, Monty Taylor wrote:
On 09/04/2014 01:30 AM, Clint Byrum wrote:
Excerpts from Flavio Percoco's message of 2014-09-04 00:08:47 -0700:
Greetings,
Last Tuesday the TC h
On 09/09/14 15:03, Monty Taylor wrote:
On 09/04/2014 01:30 AM, Clint Byrum wrote:
Excerpts from Flavio Percoco's message of 2014-09-04 00:08:47 -0700:
Greetings,
Last Tuesday the TC held the first graduation review for Zaqar. During
the meeting some concerns arose. I've listed those concerns b
On Tue, 2014-09-09 at 12:05 -0700, Gilbert Pilz wrote:
> I have a question with regards to splitting expressions in order to
> conform to the pep8 line-length restriction. I have the following bit
> of code:
>
>
> res = amodel.Assemblies(uri=common.ASSEM_URI_STR %
>
On 09/11/2014 03:01 PM, Jay Pipes wrote:
On 09/11/2014 04:51 PM, Matt Riedemann wrote:
On 9/10/2014 6:00 PM, Russell Bryant wrote:
On 09/10/2014 06:46 PM, Joe Cropper wrote:
Hmm, not sure I follow the concern, Russell. How is that any different
from putting a VM into the group when it’s boote
On 09/11/2014 03:15 AM, Richard Jones wrote:
[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
On Thu, Sep 11, 2014 at 11: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 our community.
>
> I'd like to propose that we add Din
Roman,
In the workflow with 2 package repositories per 1 fuel branch set
(e.g. icehouse & juno for 6.0, or juno & kilo later in 6.0 release
cycle), we should aim to keep packages targeted for both repositories
as close as possible, so default mode of operation should be to put
new packages in both
On 09/11/2014 04:51 PM, Matt Riedemann wrote:
On 9/10/2014 6:00 PM, Russell Bryant wrote:
On 09/10/2014 06:46 PM, Joe Cropper wrote:
Hmm, not sure I follow the concern, Russell. How is that any different
from putting a VM into the group when it’s booted as is done today?
This simply defers t
On 9/10/2014 6:00 PM, Russell Bryant wrote:
On 09/10/2014 06:46 PM, Joe Cropper wrote:
Hmm, not sure I follow the concern, Russell. How is that any different
from putting a VM into the group when it’s booted as is done today?
This simply defers the ‘group insertion time’ to some time after
What would be your suggestions then on the issue? We want to avoid breaking
of our fuel-library and other code without knowing about it, so it's not an
option to simply forget about compatibility with Icehouse packages.
And I'm actually +1 for introducing Kilo CI jobs as soon as we can, so to
keep
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 appl
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 b
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
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
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
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 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
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 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
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
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
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. 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
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
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
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
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
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
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,
+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 c
On 09/11/2014 12:50 AM, Jesse Pretorius wrote:
On 10 September 2014 17:20, Chris Friesen mailto: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 activ
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 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
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
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 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
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 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
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
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,
> 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
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),
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
>
> 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 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.
On Thu, Sep 11, 2014 at 5:58 PM, Tomasz Napierala
wrote:
>
> On 11 Sep 2014, at 09:19, Mike Scherbakov
> wrote:
>
> > Hi all,
>
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
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
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 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 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
> +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 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
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
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
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
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
+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
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
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 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 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 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
> 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
> 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
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
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
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,
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,
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 wi
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
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 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
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/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
> 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
1 - 100 of 135 matches
Mail list logo
