On 02/12/2015 10:40 AM, Alexander Makarov wrote:
A trust token cannot be used to get another token:
https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156
You have to make your Nova client use the very same trust scoped token
obtained from authentication using
On Wed, Feb 11, 2015 at 7:53 AM, Doug Hellmann
wrote:
>
>
> On Tue, Feb 10, 2015, at 07:12 PM, Joe Gordon wrote:
> > Hi,
> >
> > As you know a few of us have been spending way too much time digging
> > stable/juno out of the ditch its currently in. And just when we thought
> > we
> > were in the
On 02/12/2015 01:08 PM, Jay Pipes wrote:
> On 02/12/2015 01:01 PM, Chris Dent wrote:
>> I meant to get to this in today's meeting[1] but we ran out of time
>> and based on the rest of the conversation it was likely to lead to a
>> spiral of different interpretations, so I thought I'd put it up here
Thierry Carrez writes:
> So what is it we actually want for that repository ? In a world where
> Gerrit can do anything, what would you like to have ?
>
> Personally, I want our technical community in general, and our PTLs/CPLs
> in particular, to be able to record their opinion on the proposed
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
there were some moves recently to make monkey patching strategy sane
in neutron.
This was triggered by some bugs found when interacting with external
oslo libraries [1], and a cross project spec to make eventlet usage
sane throughout the proj
Hi Tim,
Thanks for your response. Excited too to extend the collaboration and ensure
there is no need to duplicate effort in the open source community.
My responses inline.
1) Choice of LP solver.
I see solver-scheduler uses Pulp, which was on the Congress short list as well.
So we’re high
On Thu, 12 Feb 2015, Flavio Percoco wrote:
On 11/02/15 11:24 +, Chris Dent wrote:
I think it is time we recognize and act on the fact that the corporate
landlords that pay many of us to farm on this land need to provide more
resources. This will help to ensure the health of semi-artifical
op
On Thu, Feb 12, 2015 at 3:59 AM, Tomasz Napierala
wrote:
>
> > On 10 Feb 2015, at 23:02, Andrew Woodward wrote:
> >
> > previously we used squid in 3.0 and before. The main problem is that the
> deployment would proceeded even if not all the packages where cached or
> even available on the remot
On Thu, Feb 12, 2015, at 02:17 PM, Joe Gordon wrote:
> On Wed, Feb 11, 2015 at 7:53 AM, Doug Hellmann
> wrote:
>
> >
> >
> > On Tue, Feb 10, 2015, at 07:12 PM, Joe Gordon wrote:
> > > Hi,
> > >
> > > As you know a few of us have been spending way too much time digging
> > > stable/juno out of t
On Thu, Feb 12, 2015 at 2:22 PM, Doug Hellmann
wrote:
> It's Thursday, so we're outside of the Oslo team's release window, so we
>
I didn't know this was a thing. Thank You! Now let's point some other
upstream maintainers in this direction... ;)
dt
/me crawls back into venv-land
--
Dean Tro
On 2/12/15, 12:01, "Chris Dent" wrote:
>
>I meant to get to this in today's meeting[1] but we ran out of time
>and based on the rest of the conversation it was likely to lead to a
>spiral of different interpretations, so I thought I'd put it up here.
>
>$SUBJECT says it all: When writing guidelin
Yep, that's what i'm looking for, thanks,
another notification from nova that is missed in ceilometer is info from nova
api:
https://github.com/openstack/nova/blob/master/nova/notifications.py#L64
this notify_decorator will decorate every nova/ec2 rest api and send out a
notification for each ap
On Wed, Feb 11, 2015 at 12:06 PM, Dan Prince wrote:
> I wanted to take a few minutes to go over the progress we've made with
> TripleO Puppet in Kilo so far.
>
> For those unfamilar with the efforts our initial goal was to be able to
> use Puppet as the configuration tool for a TripleO deployment
On Wed, Jan 28, 2015, at 08:25 AM, Thierry Carrez wrote:
> Hi everyone,
>
> When we first introduced the cross-project specs (specs for things that
> may potentially affect all OpenStack projects, or where more convergence
> is desirable), we defaulted to rather simple rules for approval:
>
> -
On Thu, Feb 12, 2015, at 03:47 PM, Dean Troyer wrote:
> On Thu, Feb 12, 2015 at 2:22 PM, Doug Hellmann
> wrote:
>
> > It's Thursday, so we're outside of the Oslo team's release window, so we
> >
>
> I didn't know this was a thing. Thank You! Now let's point some other
> upstream maintainers i
Hi folks,
Here is another way to do this. Lu had mentioned Oozie shell actions
previously.
Sahara doesn't support them, but I played with it from the Oozie command
line
to verify that it solves our hbase problem, too.
We can potentially create a blueprint to build a simple Shell action
around a
Hmm, my attachments were removed :)
Well, the interesting parts were the doit.sh and workflow.xml:
$ more doit.sh
#!/bin/bash
/usr/lib/jvm/java-7-oracle-cloudera/bin/java -cp HBaseTest.jar:`hbase
classpath` HBaseTest
$ more workflow.xml
${jobTracker}
Bryan and Zhipeng,
Sean Roberts (CCed) is planning to be in Santa Rosa. Sean’s definitely there
on Wed. Less clear about Thu/Fri.
I don’t know if I’ll make the trip yet, but I’m guessing Wed early afternoon if
I can.
Tim
On Feb 11, 2015, at 9:04 PM, SULLIVAN, BRYAN L
mailto:bs3...@att.com
This was discussed in the nova meeting this morning. In that meeting
we declared ourselves unwedged and ready to do a release, and I said
I'd do that today.
On reflection, I want to recant just a little -- I think its a bad
idea for me to do a release on a Friday. So, I'll do this early next
week
I'm happy to sponsor this. I've reviewed all the patches as well and as
Claudiu mentions we have this lined up as being the first api change to use
microversions
Regards,
Chris
On Thu, Feb 12, 2015 at 10:50 PM, Claudiu Belu wrote:
>
> Hello.
>
> I would like to ask for a FFE for the x509 keyp
2015-02-12 21:20 GMT+09:00 Claudiu Belu :
>
> Hello.
>
> I would like to ask for a FFE for the x509 keypairs blueprint:
> https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates
>
> This blueprint is split up into 3 commits:
>
> [1] Database migration: previously merged, but had to be
Why did the services fail with the stdlib patched? Are they incompatible
with eventlet?
On Thu, Feb 12, 2015 at 11:25 AM, Ihar Hrachyshka
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> there were some moves recently to make monkey patching strategy sane
> in neutron.
>
Hi Brian, thanks for the response. Some comments inline :)
On 02/11/2015 09:57 AM, Brian Rosmaita wrote:
On 2/9/15, 8:44 PM, "Joe Gordon" mailto:joe.gord...@gmail.com>> wrote:
On Mon, Feb 9, 2015 at 1:22 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote:
On 01/20/2015 10:54 AM, Bria
I agree with you @Chris
'--force' flag is a good idea, it keep backward compatibility and
flexibility.
We can select whether the filters was applied for force_hosts.
I will register blueprint to trace the feature.
The 'force_hosts' feature is so age-old that I don't know how many users
had used it
THX Tim!
I think It'd be great if we could have some online discussion ahead of F2F
LFC summit.We could have the crash course early next week (Monday or
Tuesday), and then Bryan could discuss with Sean in detail when they met,
with specific questions.
Would this be ok for everyone ?
On Fri, Feb
On 5 February 2015 at 13:20, Rochelle Grober wrote:
> Duncan Thomas [mailto:duncan.tho...@gmail.com] on Wednesday, February 04,
> 2015 8:34 AM wrote:
>
>
>
> The downside of numbers rather than camel-case text is that they are less
> likely to stick in the memory of regular users. Not a huge think
Append blueprint link:
https://blueprints.launchpad.net/nova/+spec/verifiable-force-hosts
2015-02-13 10:48 GMT+08:00 Rui Chen :
> I agree with you @Chris
> '--force' flag is a good idea, it keep backward compatibility and
> flexibility.
> We can select whether the filters was applied for force_ho
So inspired by the "Rootwrap on root-intensive nodes" thread, I went and
wrote a proof-of-concept privsep daemon for neutron:
https://review.openstack.org/#/c/155631
There's nothing neutron-specific in the core mechanism and it could easily
be moved out into a common (oslo) library and reused acros
All,
Several members of the Cinder team and I were discussing the current
state of volume replication while trying to figure out the best way to
resolve bug 1383524 [1]. The outcome of the discussion was a decision
to hold off on integrating volume replication support for additional
drivers.
On 13 Feb 2015 17:42, "Angus Lees" wrote:
>
> So inspired by the "Rootwrap on root-intensive nodes" thread, I went and
wrote a proof-of-concept privsep daemon for neutron:
https://review.openstack.org/#/c/155631
> There's nothing neutron-specific in the core mechanism and it could
easily be moved
On Fri Feb 13 2015 at 4:05:33 PM Robert Collins
wrote:
>
> On 13 Feb 2015 17:42, "Angus Lees" wrote:
> >
> > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and
> wrote a proof-of-concept privsep daemon for neutron:
> https://review.openstack.org/#/c/155631
> > There's nothi
ᐧ
>
> from neutron.agent.privileged.commands import ip_lib as priv_ip
> def foo():
> # Need to create a new veth interface pair - that usually requires
> root/NET_ADMIN
> priv_ip.CreateLink('veth', 'veth0', peer='veth1')
>
> Because we now have elevated privileges directly
Ryu/ofagent CI will be offline during this weekend.
sorry for inconvenience.
YAMAMOTO Takashi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
yea, this patch is on good shape.
2015-02-13 9:05 GMT+08:00 Ken'ichi Ohmichi :
> 2015-02-12 21:20 GMT+09:00 Claudiu Belu :
> >
> > Hello.
> >
> > I would like to ask for a FFE for the x509 keypairs blueprint:
> > https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates
> >
> > This b
101 - 134 of 134 matches
Mail list logo
