Hi all, just to let you know that on request from Thai I split the REST API
change into two:
https://review.openstack.org/#/c/136676
- original change which just has the base code
https://review.openstack.org/#/c/139532
- keystone specifics
The identity WIP should now base itself off the sec
Hi Brandon,
Yeah, in your example, member1 could potentially have 8 different statuses
(and this is a small example!)... If that member starts flapping, it means
that every time it flaps there are 8 notifications being passed upstream.
Note that this problem actually doesn't get any better if we
Thank you for the response.
I updated the following patch with the idea.
https://review.openstack.org/#/c/138342/
On Friday, December 05, 2014 5:50 AM, Clay Gerrard wrote:
> more fidelity in the recon's seems fine, statsd emissions are
> also a popular target >for telemetry radiation.
Thanks a
Hi all,
We talked about this topic (Support Modifying Volume Image Metadata) in this
week's IRC meeting. Unfortunately, I didn't prepared
well and couldn't detail one concrete use case on this spec. Apologize for
messing up the meeting!
Now, we have updated the spec and addressed some comments w
+1 I've been meaning to say something like this but never got around
to it. Thanks for speaking up.
On Thu, Dec 4, 2014 at 6:03 PM, Tony Breeds wrote:
> Hello Wiki masters,
> Is there anyway to extend the session length on the wiki? In my current
> work flow I login to the wiki do work and
On 12/04/2014 05:01 PM, Alan Pevec wrote:
2014-12-04 23:00 GMT+01:00 Jay S. Bryant :
Finally was able to get the master version through the gate and
cherry-picked it here:
https://review.openstack.org/#/c/139194/
That one has made it through the check. So, if it isn't too late, it could
use a
Hello Wiki masters,
Is there anyway to extend the session length on the wiki? In my current
work flow I login to the wiki do work and then get distracted by code/IRC when
I go back to the wiki I'm almost always logged out (I'm guessing due to
inactivity). It feels like this is about 30mins b
Sorry it's taken me a while to respond to this.
So I wasn't thinking about this correctly. I was afraid you would have
to pass in a full tree of parent child representations to /loadbalancers
to update anything a load balancer it is associated to (including down
to members). However, after think
One of the things that happens over time is that some of our core
reviewers move on to other projects. This is a normal and healthy
thing, especially as nova continues to spin out projects into other
parts of OpenStack.
However, it is important that our core reviewers be active, as it
keeps them u
Excerpts from Gregory Haynes's message of 2014-12-04 15:20:53 -0800:
> Hello TripleOers,
>
> I got a patch together to move us off of our upstart exec |
> logger -t hack [1] and this got me wondering - why aren't we
> using the python logging.conf supported by most OpenStack projects [2]
> to wr
On 12/04/2014 05:41 AM, Clint Byrum wrote:
What if the patch is reworked to leave the current trace-all-the-time
mode in place, and we iterate on each script to make tracing conditional
as we add proper logging?
I have run [1] over patchset 15 to keep whatever was originally using
-x tracing it
Hello TripleOers,
I got a patch together to move us off of our upstart exec |
logger -t hack [1] and this got me wondering - why aren't we
using the python logging.conf supported by most OpenStack projects [2]
to write out logs to files in our desired location?
This is highly desirable for a c
> Filed as https://bugs.launchpad.net/oslo.messaging/+bug/1399085
> Since this is blocking stable/juno I've pushed partial revert of
> Revert "Cap Oslo and client library versions"
> https://review.openstack.org/138963
> as a quickfix before the 2014.2.1 release today.
> We'll of course need to re
2014-12-04 23:00 GMT+01:00 Jay S. Bryant :
> Finally was able to get the master version through the gate and
> cherry-picked it here:
> https://review.openstack.org/#/c/139194/
>
> That one has made it through the check. So, if it isn't too late, it could
> use a +2/+A.
Looks good and is exceptio
On 12/04/2014 05:38 PM, Matt Riedemann wrote:
>
>
> On 12/4/2014 4:06 PM, Michael Still wrote:
>> +Eric and Ian
>>
>> On Fri, Dec 5, 2014 at 8:31 AM, Matt Riedemann
>> wrote:
>>> This came up in the nova meeting today, I've opened a bug [1] for it.
>>> Since
>>> this isn't maintained by infra we
On 12/4/2014 4:06 PM, Michael Still wrote:
+Eric and Ian
On Fri, Dec 5, 2014 at 8:31 AM, Matt Riedemann
wrote:
This came up in the nova meeting today, I've opened a bug [1] for it. Since
this isn't maintained by infra we don't have log indexing so I can't use
logstash to see how pervasive it
Hi lbaas,
Just a reminder that the spec submission deadline is Dec 8th (this Monday.) If
you are working on lbaas v2 features or drivers, and had a spec in Juno, it
must be re-submitted for Kilo.
LBaaS v2 specs that are currently submitted for Kilo:
LBaaS V2 API and object model definition -
+Eric and Ian
On Fri, Dec 5, 2014 at 8:31 AM, Matt Riedemann
wrote:
> This came up in the nova meeting today, I've opened a bug [1] for it. Since
> this isn't maintained by infra we don't have log indexing so I can't use
> logstash to see how pervasive it us, but multiple people are reporting the
On 12/03/2014 01:17 PM, Alan Pevec wrote:
2014-12-02 17:15 GMT+01:00 Jay S. Bryant :
Cinder
https://review.openstack.org/137537 - small change and limited to the
VMWare driver
+1 I think this is fine to make an exception for.
one more Cinder exception proposal was added in StableJuno etherpad
On 12/4/2014 6:02 AM, Davanum Srinivas wrote:
+1 to @markmc's "default is global value and override for project
specific key" suggestion.
-- dims
On Wed, Dec 3, 2014 at 11:57 PM, Matt Riedemann
wrote:
I've posted this to the 12/4 nova meeting agenda but figured I'd socialize
it here also.
Due to the mid-cycle, and other neutron meetings being cancelled, we will not
meet on the 9th
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
This came up in the nova meeting today, I've opened a bug [1] for it.
Since this isn't maintained by infra we don't have log indexing so I
can't use logstash to see how pervasive it us, but multiple people are
reporting the same thing in IRC.
Who is maintaining the nova-docker CI and can look
Excerpts from Ben Nemec's message of 2014-12-04 11:12:10 -0800:
> FWIW, I think the "correct" thing to do here is to get our Juno jobs up
> and running and have one of them verify the nova-bm code paths for this
> cycle, and then remove it next cycle.
>
> That said, I have no idea how close we are
more fidelity in the recon's seems fine, statsd emissions are also a
popular target for telemetry radiation.
On Thu, Nov 27, 2014 at 5:01 AM, Osanai, Hisashi <
osanai.hisa...@jp.fujitsu.com> wrote:
>
> Hi,
>
> I think it is a good idea to have the object-replicator's failure info
> in recon like
Cool -- I have added these to the agenda.
Michael
On Fri, Dec 5, 2014 at 7:27 AM, Alessandro Pilotti
wrote:
> Hi Michael,
>
>> On 25 Nov 2014, at 02:35, Michael Still wrote:
>>
>> On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti
>> wrote:
>>> Hi Michael,
>>>
On 25 Nov 2014, at 01:57,
Hi Michael,
> On 25 Nov 2014, at 02:35, Michael Still wrote:
>
> On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti
> wrote:
>> Hi Michael,
>>
>>> On 25 Nov 2014, at 01:57, Michael Still wrote:
>>>
>>> First off, sorry for the slow reply. I was on vacation last week.
>>>
>>> The project p
My preference would be “change the default behavior to 'static’” for the
following reasons:
- There are plenty of ways to close the modal, so there’s not really a need for
this feature.
- There are no visual cues, such as an “X” or a Cancel button, that selecting
outside of the modal closes it.
On Thu Dec 04 2014 at 11:05:53 AM Clint Byrum wrote:
> Excerpts from Steve Kowalik's message of 2014-12-03 20:47:19 -0800:
> > Hi all,
> >
> > I'm becoming increasingly concerned about all of the code paths
> > in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use
> > nova-baremet
Original message bounced and I didn't notice.
thanks,manish
-
Subject: Re: [openstack-dev] 答复: [Neutron][L2 Agent][Debt] Bootstrapping an L2
agent debt repayment task force
Thanks Rossella. I'll take a look this week. My name is also on the etherpad
already and can help with this. Some
On 12/04/2014 02:18 PM, Adam Young wrote:
> On 12/04/2014 01:44 PM, Stefano Maffulli wrote:
>> On 12/04/2014 09:24 AM, Anita Kuno wrote:
>>> I think we move into very dangerous territory if we are equating a core
>>> review Gerrit permission (it is just a Gerrit permission, if it is
>>> perceived a
On 2014-12-03 23:24:41 + (+), Sukhdev Kapur wrote:
[...]
> If I may express my opinion, Bob's contribution to ML2 has been
> quite substantial. The kind of stability ML2 has achieved makes a
> statement of his dedication to this work. I have worked very
> closely with Bob on several issues
On Thu, Dec 4, 2014 at 1:19 PM, K, Shanthakumar (HP Cloud) <
shanthakuma...@hp.com> wrote:
> I'm trying to integrate Netapp 7 mode NFS driver with openstack cinder
> volume provisioning using Juno 2.
>
> During the driver initialization I’m getting the following error and
> volume creation is fai
On 4 December 2014 at 08:00, Neil Jerram wrote:
> Kevin Benton writes:
> I was actually floating a slightly more radical option than that: the
> idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
> absolutely _nothing_, not even create the TAP device.
>
Nova always does something
Due to the mid-cycle which is happening next week, I'm cancelling the
weekly Neutron meeting, as well as the Neutron Drivers meeting. The meeting
page has been updated for both meetings [1] [2].
Thanks!
Kyle
[1] https://wiki.openstack.org/wiki/Network/Meetings
[2] https://wiki.openstack.org/wiki/
> On Dec 4, 2014, at 11:04 AM, Clint Byrum wrote:
>
> Excerpts from Steve Kowalik's message of 2014-12-03 20:47:19 -0800:
>> Hi all,
>>
>>I'm becoming increasingly concerned about all of the code paths
>> in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use
>> nova-baremetal ra
Hi All,
I'm trying to integrate Netapp 7 mode NFS driver with openstack cinder volume
provisioning using Juno 2.
During the driver initialization I'm getting the following error and volume
creation is failing.
Do I need to do any changes in storage or client side ?
Please refer the log below
On 1 December 2014 at 21:26, Mohammad Hanif wrote:
> I hope we all understand how edge VPN works and what interactions are
> introduced as part of this spec. I see references to neutron-network
> mapping to the tunnel which is not at all case and the edge-VPN spec
> doesn’t propose it. At a ve
On 12/04/2014 01:44 PM, Stefano Maffulli wrote:
On 12/04/2014 09:24 AM, Anita Kuno wrote:
I think we move into very dangerous territory if we are equating a core
review Gerrit permission (it is just a Gerrit permission, if it is
perceived as anything other than that that is a perception we have
FWIW, I think the "correct" thing to do here is to get our Juno jobs up
and running and have one of them verify the nova-bm code paths for this
cycle, and then remove it next cycle.
That said, I have no idea how close we are to actually having Juno jobs
and I agree that we have no idea if the nova
Excerpts from Steve Kowalik's message of 2014-12-03 20:47:19 -0800:
> Hi all,
>
> I'm becoming increasingly concerned about all of the code paths
> in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use
> nova-baremetal rather than Ironic. We do not check nova-bm support in
> CI, ha
On 12/04/2014 09:24 AM, Anita Kuno wrote:
> I think we move into very dangerous territory if we are equating a core
> review Gerrit permission (it is just a Gerrit permission, if it is
> perceived as anything other than that that is a perception we have
> created ourselves) with value as an OpenSta
On Thu, Dec 4, 2014 at 12:06 PM, Paul Belanger
wrote:
> On Mon, Oct 6, 2014 at 6:58 AM, S M, Praveen Kumar
> wrote:
>>
>> Please let me know your inputs on this.
>>
> Did you ever resolve this? I'm also seeing this ImportError too.
>
Thanks to dhellmann for the help, my issue was related to setu
Hi Irena,
Thanks for response. we made the change to have same network across all the
compute nodes.
After the change we are getting the new error saying the binding failed for
the vif port when we create the VM.
FYI: Please find the complete logs below
Neutron/server.log
2014-12-04 18:35:02.4
On 12/04/2014 05:21 AM, Mathieu Rohon wrote:
> On Thu, Dec 4, 2014 at 8:38 AM, Sumit Naiksatam
> wrote:
>> On Wed, Dec 3, 2014 at 9:07 PM, Adam Young wrote:
>>> On 12/03/2014 06:24 PM, Sukhdev Kapur wrote:
>>>
>>> Congratulations Henry and Kevin. It has always been pleasure working with
>>> you g
Just throwing in my two cents:
Multiple times, I've lost typed in data in Horizon because I've accidentally
pressed escape without thinking (I use Vim, so pressing escape when I'm done
typing is second nature). While clicking the 'x' button is often deliberate,
pressing escape can be accidenta
On Thu, Dec 4, 2014 at 3:35 PM, Jay Dobies wrote:
> As an example of something that I think doesn't add much value in the
>>> meeting - DerekH has already been giving semi-regular CI/CD status
>>> reports via email. I'd like to make these weekly update emails
>>> regular, and take the update off
Hi Vadivel,
We do have a blueprint in the docs-specs repo under review for driver
documentation and I'd like to get your input.
https://review.openstack.org/#/c/133372/
Here's a relevant excerpt:
The documentation team will fully document the reference drivers as
specified below and just add shor
On Thu, Dec 4, 2014 at 11:40 AM, marios wrote:
> On 04/12/14 11:40, James Polley wrote:
> > Just taking a look at http://doodle.com/27ffgkdm5gxzr654 again - we've
> > had 10 people respond so far. The winning time so far is Monday 2100UTC
> > - 7 "yes" and one "If I have to".
>
> for me it curren
On Mon, Oct 6, 2014 at 6:58 AM, S M, Praveen Kumar
wrote:
> Hello All,
>
>
>
> We are trying to integrate openstack with java.
>
>
>
> While doing so we are facing “ImportError: No module named urllib”
>
>
>
> When we import from python console it works fine.
>
>
>
> However when we are trying to
The more I think on it. I agree with Rob Cresswell comment "While
clicking off the modal is relatively easy to do my accident, hitting Esc
or 'X' are fairly distinct actions."
While there is nothing wrong with warning the user that they will lose
data after they clicked the 'x' / 'esc'... T
Hi
AFAIK there are no products out there using tripleo&nova-bm, but maybe a quick
post to -operators asking if this will ruin anyone's day, would be good?
Cheers,
--
Chris Jones
> On 4 Dec 2014, at 04:47, Steve Kowalik wrote:
>
> Hi all,
>
>I'm becoming increasingly concerned about all o
Sorry for the late announce, too much turkey and pie
This Friday, Dec 5th, we'll be talking with Steve Martinelli and David
Stanek about Keystone Authentication in OpenStack.
The keys to the kingdom, Keystone! For this bootstrapping hour Steve and
David will talk about using Keystone, OpenSta
> Hello Frank,
>
> Some times, I've seen that modules are missing even in the stable
> branches, try to install the module independently and this should
> fix your issue.
>
> Best regards, Venu
>
>
> > On Thu, Dec 4, 2014 at 11:58 AM, Du Jun wrote:
> >
> > Hi all,
> >
> > I think I find a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/04/2014 09:50 AM, Kyle Mestery wrote:
> Is ipset support present in all supported distributions?
>
>
> It is from Red Hat perspective, not sure Ubuntu, and the others, I think
> Juno was targeted to ubuntu 14.04 only (which does have ipset ker
Kevin Benton writes:
> What you are proposing sounds very reasonable. If I understand
> correctly, the idea is to make Nova just create the TAP device and get
> it attached to the VM and leave it 'unplugged'. This would work well
> and might eliminate the need for some drivers. I see no reason to
Hi Kyle and all,
Was there any conclusion in the design summit or the meetings afterward
about splitting the vendor plugins/drivers from the mainstream neutron and
documentation of out-of-tree plugins/drivers?...
Thanks,
Vad
--
On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery wrote:
> On Thu, O
Note: Similar to Nova, cross-posting to operators.
We've published the list of priorities for Neutron during the Kilo cycle,
and it's available here [1]. The team has been discussing these since
before the Paris Summit, and we're in the process of approving individual
specs around these right now.
Hello Dmitry,
This is off the topic of original email but related to RBD.
Looking through the code of LibvirtDriver._get_instance_disk_info() I
noticed that it only returns data for disks with or
but not so RBD backed instances
would be incorrectly reported to have no ephemeral disks. I do
On 12/04/2014 09:29 AM, Alan Pevec wrote:
>> I'd like to request another exception for Neutron to avoid introducing
>> regression in hostname validation for DNS nameservers:
>> https://review.openstack.org/#/c/139061/
>
> Nice solution for this regression, I think it's worthy last-minute exception
At the kilo summit third-party session we discussed the need for a complete
overhaul of the third-party CI documentation. Several in attendance
volunteered to help with this effort.
To help get us started, I have created an etherpad to help organize the
thoughts of those involved.
https://etherpad
Minutes:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-12-04-14.02.html
Log:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-12-04-14.02.log.html
On Thu, Dec 4, 2014 at 3:49 PM, Sergey Lukjanov
wrote:
> Hi folks,
>
> We'll be having the Sahara team meeting in
>
Hi all,
Note: Cross posting with operators
After a long double slot summit session, the nova team has come up with its
list of efforts to prioritize for Kilo:
http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html
What does this mean?
* This is a list of items we think
Nikolay,
I'd recommend taking a look at the work I did for the Barbican project in
converting their falcon-based API to pecan:
https://review.openstack.org/#/c/89746
...because it makes use of a pecan feature called "generic controllers" for
defining RESTful interfaces:
https://review.openstack
On Thu, Dec 4, 2014 at 8:40 AM, Miguel Ángel Ajo wrote:
>
>
> On Thursday, 4 de December de 2014 at 15:19, Ihar Hrachyshka wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Thursday, 4 de December de 2014 at 15:06, Miguel Ángel Ajo
> wrote:
>
>
>
> During Juno, we introduced the
On 12/04/2014 03:19 PM, Ihar Hrachyshka wrote:
> Is ipset support present in all supported distributions?
SUSE distributions support ipset.
+1 for Miguel Angel's proposal
cheers,
Rossella
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack
On Thursday, 4 de December de 2014 at 15:19, Ihar Hrachyshka wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> > On Thursday, 4 de December de 2014 at 15:06, Miguel Ángel Ajo
> > wrote:
> >
> > >
> > >
> > > During Juno, we introduced the enhanced security groups rpc
> >
As an example of something that I think doesn't add much value in the
meeting - DerekH has already been giving semi-regular CI/CD status
reports via email. I'd like to make these weekly update emails
regular, and take the update off the meeting agenda. I'm offering to
share the load with him to ma
Ryan, can you please provide some more links on how these features
what I described are implemented in Pecan? Some working examples,
maybe? As far as I see now, each OpenStack project uses its own
approach to integration with Pecan, so what will you recommend to look
at?
On Thu, Dec 4, 2014 at 4:1
> I'd like to request another exception for Neutron to avoid introducing
> regression in hostname validation for DNS nameservers:
> https://review.openstack.org/#/c/139061/
Nice solution for this regression, I think it's worthy last-minute exception.
Should VMT also send this officially to the ven
+1, FWIW.
Alexis
+1
This is similar to the no merge.py discussion. If something isn't
covered by CI, it's going to grow stale pretty quickly.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/12/14 14:22, Alan Pevec wrote:
> Hi all,
>
> here are exception proposal I have collected when preparing for
> the 2014.2.1 release, stable-maint members please have a look!
>
>
> General: cap Oslo and client library versions - sync from
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
> On Thursday, 4 de December de 2014 at 15:06, Miguel Ángel Ajo
> wrote:
>
>>
>>
>> During Juno, we introduced the enhanced security groups rpc
>> (security_groups_info_for_devices) instead of
>> (security_group_rules_for_devices), and the ipset
The Oslo team is pleased to announce the release of
oslo.messaging 1.5.1: Oslo Messaging API
This release reintroduces the 'fake_rabbit' config option.
For more details, please see the git log history below and
https://launchpad.net/oslo.messaging//+milestone/1.5.1
Please report issues throug
I'd like to get a bit better data on where we're spending all our time
in tests in Nova (and just in general).
It doesn't appear there is a clear way to do that with testr. The
following wraps the tests runs in cProfile -
https://review.openstack.org/#/c/138440/2/tools/profile.py,cm
However, as w
Sorry, adding [neutron] to the subject.
Miguel Ángel Ajo
On Thursday, 4 de December de 2014 at 15:06, Miguel Ángel Ajo wrote:
>
>
> During Juno, we introduced the enhanced security groups rpc
> (security_groups_info_for_devices) instead of
> (security_group_rules_for_devices),
> and th
Hi Aaron,
The only way to combine 2 aforementioned solutions I've been thinking of is
to implement David's solution as the 4th option (in addition to
true|false|static) on a per-form basis, leaving the possibility to change
the default value in configs. I guess this sort of combining would be as
s
During Juno, we introduced the enhanced security groups rpc
(security_groups_info_for_devices) instead of
(security_group_rules_for_devices),
and the ipset functionality to offload iptable chains a bit.
Here I propose to:
1) Remove the old security_group_info_for_devices, which was left to
Dan Prince said on Thu, Dec 04, 2014 at 08:09:56AM -0500:
> > face of backwards-compatibility, but do we want to bite the bullet and
> > remove nova-bm support?
+1, FWIW.
Alexis
--
Nova Engineer, HP Cloud. AKA lealexis, lxsli.
___
OpenStack-dev mail
On Thu, 2014-12-04 at 11:51 +, Derek Higgins wrote:
> A month since my last update, sorry my bad
>
> since the last email we've had 5 incidents causing ci failures
>
> 26/11/2014 : Lots of ubuntu jobs failed over 24 hours (maybe half)
> - We seem to suffer any time an ubuntu mirror isn't in s
On Wed, Dec 3, 2014 at 3:31 PM, Mike Scherbakov
wrote:
> Hi all,
> enable_new_services in nova.conf seems to allow add new compute nodes in
> disabled state:
>
> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L507-L508,
> so it would allow to check everything first, befor
On Thu, 2014-12-04 at 10:11 +0100, James Polley wrote:
> Hi all,
>
>
> The other topic that has come up a few times in our meetings is: what
> value do we get from these meetings?
Often. Not much. :( Partially my own fault too since I haven't been good
about adding items to the agenda myself ah
v3 API is now moving to v2.1, but the definition of the api module and
the json schema for v2.1 still go on v3 folder. I posted a question
about v2 vs v3 API on this mailing list not long ago and got useful tips
by Christopher Yeoh, maybe it will be useful for you too to give at
check at them:
I’d rather suggest doing in several iteration by replacing several resources by
Pecan’s implementations.
Doing that in one big patch-set will make reviewing very painful, so some bad
things might be not noticed.
> On 04 Dec 2014, at 14:01, Igor Kalnitsky wrote:
>
> Ok, guys,
>
> It became ob
On Thu, 2014-12-04 at 15:47 +1100, Steve Kowalik wrote:
> Hi all,
>
> I'm becoming increasingly concerned about all of the code paths
> in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use
> nova-baremetal rather than Ironic. We do not check nova-bm support in
> CI, haven't for
Ok, guys,
It became obvious that most of us either vote for Pecan or abstain from voting.
So I propose to stop fighting this battle (Flask vs Pecan) and start
thinking about moving to Pecan. You know, there are many questions
that need to be discussed (such as 'should we change API version' or
's
Hi, Christopher,
I working on API extension for instance tags (
https://review.openstack.org/#/c/128940/). Recently one reviewer asked me
to add V3 API support. I talked with Jay Pipes about it and he told me
that V3 API became useless. So I wanted to ask you and our community: "Do
we need to sup
Hi folks,
We'll be having the Sahara team meeting in
#openstack-meeting-3 channel.
Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20141204T14
NOTE: There is another time slot and meeting roo
On Thu, Dec 04, 2014 at 09:25:00AM +0100, Nikola Đipanov wrote:
> On 12/04/2014 05:30 AM, Michael Still wrote:
> > Hi,
> >
> > so just having read a bunch of the libvirt driver numa code, I have a
> > concern. At first I thought it was a little thing, but I am starting
> > to think its more of a b
On Thu, Dec 04, 2014 at 03:30:46PM +1100, Michael Still wrote:
> Hi,
>
> so just having read a bunch of the libvirt driver numa code, I have a
> concern. At first I thought it was a little thing, but I am starting
> to think its more of a big deal...
>
> We use the term "cells" to describe numa c
While clicking off the modal is relatively easy to do my accident, hitting Esc
or ‘X’ are fairly distinct actions. I don’t personally think there is any need
to warn the user in that instance :)
Rob
On 3 Dec 2014, at 22:30, Aaron Sahlin
mailto:asah...@linux.vnet.ibm.com>> wrote:
I would be h
As a (late) reminder, the Oslo team is sprinting today to clear out our bug
triage and review backlog. Please join us in #openstack-oslo to participate!
Doug
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/c
On Dec 3, 2014, at 3:45 PM, Sean Dague wrote:
> So this -
> https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
> was clearly a violation of our 1 cycle for deprecation of config options.
>
> I think that should be reverted, an oops release put out to fix
On Dec 3, 2014, at 3:44 PM, John Griffith wrote:
> Hey,
>
> So this is a long running topic, but I want to bring it up again.
> First, YES Cinder is still running a sample.conf. A lot of Operators
> spoke up and provided feedback that this was valuable and they
> objected strongly to taking it
+1 to @markmc's "default is global value and override for project
specific key" suggestion.
-- dims
On Wed, Dec 3, 2014 at 11:57 PM, Matt Riedemann
wrote:
> I've posted this to the 12/4 nova meeting agenda but figured I'd socialize
> it here also.
>
> SSL options - do we make them per-project
A month since my last update, sorry my bad
since the last email we've had 5 incidents causing ci failures
26/11/2014 : Lots of ubuntu jobs failed over 24 hours (maybe half)
- We seem to suffer any time an ubuntu mirror isn't in sync causing hash
mismatch errors. For now I've pinned DNS on our pro
On 17/11/14 10:12, Matthias Runge wrote:
> On 30/10/14 13:13, Matthias Runge wrote:
>> Hi,
>>
>> tl;dr: how to progreed in separating horizon and openstack_dashboard
> Options so far:
In yesterday's horizon meeting, we canceled the repo split[1]
In the light of moving to a more angular based imp
2014-12-03 22:10 GMT+01:00 Ben Nemec :
> On 12/03/2014 02:45 PM, Sean Dague wrote:
>> So this -
>> https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
>> was clearly a violation of our 1 cycle for deprecation of config options.
>>
>> I think that should be re
On Wed, 2014-12-03 at 02:08 -0800, Kevin Benton wrote:
> There is a current blueprint under discussion[1] which would have
> covered the external network access control as well, however it looks
> like the scope is going to have to be reduced for this cycle so it
> will be limited to shared network
Hi,
I think it's better to ask this question at ask.openstack.org or the
openstack mailing list.
BR,
Itzik
On 12/04/2014 12:26 PM, Akilesh K wrote:
Hi,
I am using neutron-plugin-sriov-agent.
I have configured pci_whitelist in nova.conf
I have configured ml2_conf_sriov.ini.
But when I laun
On 04/12/14 11:40, James Polley wrote:
> Just taking a look at http://doodle.com/27ffgkdm5gxzr654 again - we've
> had 10 people respond so far. The winning time so far is Monday 2100UTC
> - 7 "yes" and one "If I have to".
for me it currently shows 1200 UTC as the preferred time.
So to be clear, w
1 - 100 of 107 matches
Mail list logo
