r services that use Heat internally) wouldn't need a change to
Heat's policy.json.
If that kind of approach is feasible I'd be happy to submit a change.
Cheers,
Johannes
--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smi
Hello,
Thanks for the exhaustive comment on the issue. Won't help much in the short
term, but it's good to see there will eventually be a way to sort this out
properly!
On 07/04/2016 12:50 PM, Steven Hardy wrote:
On Mon, Jul 04, 2016 at 11:43:47AM +0200, Johannes Grassler wrote:
master branch. Are they slated for removal at some stage or will they remain
available even as Senlin becomes the go-to mechanism for autoscaling?
Cheers,
Johannes
--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham
Hello,
On 07/04/2016 02:52 PM, Thomas Herve wrote:
On Mon, Jul 4, 2016 at 2:06 PM, Johannes Grassler wrote:
[...]
Right now OS::Heat::AutoScalingGroup and friends still exist, even in the
master branch. Are they slated for removal at some stage or will they remain
available even as Senlin
dates-part-1-trusts.html
[2] https://wiki.openstack.org/wiki/Keystone/Trusts
--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany
_
make it a lot easier. I'll give it a
try...
Cheers,
Johannes
Best regards,
Hongbin
-Original Message-
From: Johannes Grassler [mailto:jgrass...@suse.de]
Sent: July-06-16 9:40 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [magnum] Use Keystone trusts in M
n stack-delete as it happened in the original bug report or due
to an operator accidently deleting resources that are managed by Heat.
--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 904
Hello,
On 03/07/2016 04:48 PM, Zane Bitter wrote:
On 04/03/16 04:35, Johannes Grassler wrote:
[Uncaught client exceptions in resource plugins' add_dependencies() methods]
Yes, you're right and this sucks. That's not the only problem we've had in
this area recently - for ex
Hello,
On 03/07/2016 04:48 PM, Zane Bitter wrote:
On 04/03/16 04:35, Johannes Grassler wrote:
[Uncaught client exceptions in resource plugins' add_dependencies() methods]
In the meantime, we need to find and squash every instance of this problem
wherever we can like you said.
It might
Hello,
On 03/08/2016 04:57 PM, Zane Bitter wrote:
On 08/03/16 10:40, Johannes Grassler wrote:
On 03/07/2016 04:48 PM, Zane Bitter wrote:
On 04/03/16 04:35, Johannes Grassler wrote:
[Uncaught client exceptions in resource plugins' add_dependencies()
methods]
In the meantime, we need to
On 03/08/2016 06:26 PM, Zane Bitter wrote:
On 08/03/16 08:03, Johannes Grassler wrote:
I think you're being a little too pessimistic. I was going to explain one
approach, but it turned out to be easier to just submit a patch:
https://review.openstack.org/290027
Ah, that one looks good, t
nce to get anything meaningful in.
So +1 for Stein from my side. This time I can plan for and accomodate it
by having less Monasca stuff on my plate...
Cheers,
Johannes
--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Nor
Hello,
On Fri, Jul 13, 2018 at 03:50:33PM -0500, Lance Bragstad wrote:
> On 07/13/2018 03:37 PM, Johannes Grassler wrote:
> > On Fri, Jul 13, 2018 at 02:19:35PM -0500, Lance Bragstad wrote:
> >> *Capability Lists**
> >> *
> >> The capability lists involves a l
way to grant roles on a domain by name would also solve the
problem...
Cheers,
Johannes
[0]
https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/role.py#L241
--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix
Hello,
On 09/20/2016 10:15 AM, Johannes Grassler wrote:
is there a canonical way to either
* list roles in a given domain
* or retrieve a role from a given domain by name (preferred)
Looks like there is a way:
osc_lib.utils.find_resource(admin_client.roles, role_name,
domain_id
a cleaner way to get that
information directly from the keystoneclient.client.v3.Client
instance?
Cheers,
Johannes
--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithar
Hello,
On 10/14/2016 02:27 AM, Jamie Lennox wrote:
On 13 October 2016 at 23:19, Johannes Grassler wrote:
[Is there a canonical way to extract the identity URL being used by
python-keystoneclient?]
[...]
keystone_service=client.services.list(type='identity')[0]
client.endp
!
Cheers,
Johannes
Footnotes:
[0] In a pinch I could probably ask a colleague to stand in for me, but I'd
prefer a solution where I can be present for both discussions.
--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH,
Hello,
On 10/21/2016 03:07 PM, Steve Martinelli wrote:
On Fri, Oct 21, 2016 at 5:01 AM, Johannes Grassler
wrote:
I've got a last minute proposal, or rather two of them for the Keystone
side of the design sessions in Barcelona.
[...]
The Authorization work session is more than approp
19 matches
Mail list logo