[openstack-dev] [Ceilometer] Issues with transformers

into fixing it? Hope someone is able to help. Also, as a side note, I'm working off Havana as notification based metrics for the compute agent don't seem to be working on master. Cheers, -Adrian Turjak ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [Ceilometer] Issues with transformers

On 27/01/14 23:41, Julien Danjou wrote: On Mon, Jan 27 2014, Adrian Turjak wrote: I created a gauge metric that is updated via notifications, and a pollster. The data from both of those needs to be transformed in to a cumulative metric. The transformer object works as intended, but the issue

[openstack-dev] [Ceilometer]Cumulative metrics resetting

only gets passed a 'message', I don't know if there is a way to pull the needed data out from nova using only what is in the message though. Any thoughts, or suggestions as to where to start experimenting? -Adrian Turjak ___ OpenStack-dev mailing

Re: [openstack-dev] [Ceilometer]Cumulative metrics resetting

mind digging in the source, or even extending/fixing things, just need to know where to look. Cheers, -Adrian Turjak ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer]Cumulative metrics resetting

On 31/01/14 21:50, Julien Danjou wrote: On Fri, Jan 31 2014, Adrian Turjak wrote: Is it working on Havana? As I've gone through and tried all the possible state changes (reboot, suspend, pause, resize, terminate, etc), and not one triggers a poll cycle outside of the standard polling interval

Re: [openstack-dev] [nova][ceilometer] ceilometer unit tests broke because of a nova patch

On 05/02/14 10:07, Joe Gordon wrote: On Tue, Feb 4, 2014 at 2:01 AM, Julien Danjou jul...@danjou.info wrote: On Mon, Feb 03 2014, Joe Gordon wrote: We know, Ceilometer has been broken several times because of that in the past months. We know we shouldn't do that, but for now we don't have

Re: [openstack-dev] [Keystone][Horizon] User self registration and management

, and most of the useful features we'd want I assume won't be in until after Kilo. Cheers, Adrian Turjak On 15/01/15 03:26, Enrique Garcia wrote: Hi all, I'm working in a European project that uses OpenStack and I am using horizon and keystone for our users and organization management

Re: [openstack-dev] [Keystone][Horizon] User self registration and management

, Morgan Fainberg wrote: On Jan 13, 2015, at 9:06 PM, Adrian Turjak adri...@catalyst.net.nz wrote: Hello openstack-dev, I'm wondering if there is any interest or need for an open-source user registration and management service for people using OpenStack. We're currently at a point where we

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

and the user is logged out and directly write "Email" as the field label. I know, its horrible and if you update horizon it will be overriden, but probably works for the time being if you really need it ¯\_(ツ)_/¯ * Horrible Hack Finished * Itxaka On 01/15/2016 05:13 AM, Adrian Tur

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

field.label == "User Name" and not >>> request.user.is_authenticated %}Email{% else %}{{ field.label }}{% endif >>> %} >>> >>> >>> Which will check if the label is "User Name" and the user is logged out >>> and directly write &q

[openstack-dev] [Horizon] Email as User Name on the Horizon login page

that the more I dug, the more I became confused. Where exactly is the login form defined? And where exactly is the "User Name" text for the login form set? I've tried all manner of stuff to change it with no luck and I feel like I must have missed so

[openstack-dev] [keystone][horizon] new service for user management and admin tasks with keystone

back. Cheers, - Adrian Turjak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

On 19/07/16 01:49, David Stanek wrote: > On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak <adri...@catalyst.net.nz> > wrote: >> We need an MFA solution, and this doesn't seem like too terrible an option. > > > One thing to note here is that the credentials for TO

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

gmail.com> wrote:Several comments inlineOn Mon, Jul 18, 2016 at 12:20 AM, Adrian Turjak <adriant@catalyst.net.nz> wrote:Hello, I've been looking at options for doing multi-factor auth (MFA) on our infrastructure and I'm just wanting to know if the option I've decided to go with seems sensible.

[openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

in OpenStack in the way we needed or are there other paths I should be going down? Cheers, -Adrian Turjak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

On 19/07/16 03:31, Steve Martinelli wrote: > I think the change you posted could very much just > replace the existing password plugin in keystone ( > https://review.openstack.org/#/c/343422/) and not be it's own plugin. > > How about a specification instead? >

Re: [openstack-dev] [horizon] FFE Request

Access and Key Pairs are done, and I'll put up Security Groups and Floating IPs once they start moving (maintaining huge patch chains is a waste of time) Rob On 26 January 2017 at 02:09, Adrian Turjak <adri...@catalyst.net.nz> wrote: I've posted some comments on the API Access patch. T

Re: [openstack-dev] [horizon] FFE Request

rformance > perspective and both useful from end user's perspective. > > BTW, a huge +1 for this FFE! > > > > > Cheers, > Lingxian Kong (Larry) > > On Thu, Jan 26, 2017 at 9:01 AM, Adrian Turjak > <adri...@catalyst.net.nz <mailto:adri...@catalyst.net.nz>

Re: [openstack-dev] [horizon] FFE Request

+1We very much need this as the performance of that panel is awful. This solves that problem while being a fairly minor code change which also provides much better UX.On 26/01/2017 8:07 AM, Rob Cresswell wrote: o/  I'd like to request an FFE on 

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

This is exactly what something like Minstral would be fantastic for. Multi-project workflow. Rather than try and build logic like this directly into nova, looks at extending something like Minstral with a basic easy to call task.

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

t; > I've typically used heat to do this too. As it has a nice way out of the box to to undo the actions it does. > > Thanks, > Kevin > ________ > From: Adrian Turjak [adri...@catalyst.net.nz] > Sent: Wednesday, September 07, 2016 2:34 PM > To: OpenSt

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Horizon][OSC][Nova][Neutron] Launch instance > with Floating IP > > On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote: >> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote: >>> This is exactly what something like Minstral would be fantastic for. >>>

Re: [openstack-dev] [osc][keystone] User Project List

; > > On Wed, Sep 21, 2016 at 12:31 AM Adrian Turjak <adri...@catalyst.net.nz> wrote: >> >> The default keystone policy up until Newton doesn't let a user get their >> own user > > > This seems to be the crutch of your issue - can you provide an example of

Re: [openstack-dev] [osc][keystone] User Project List

On 22/09/16 10:45, Steve Martinelli wrote: > On Wed, Sep 21, 2016 at 6:34 PM, Adrian Turjak > <adri...@catalyst.net.nz <mailto:adri...@catalyst.net.nz>> wrote: > > - or update "openstack project list" with a "--auth-user" flag > that

Re: [openstack-dev] [osc][keystone] User Project List

That commit doesn't really address the problem in question though. The problem is that the OpenStack client assumes the "get user" policy in Keystone allows you to get your own user, which it didn't until Newton, and thus a lot of deployments probably are using the default policy or some variant

Re: [openstack-dev] [osc][keystone] User Project List

Worth noting, I have been playing with 3.2.0 and the same problem persists in our deployment which is running a variant of the old default keystone policy. On 22/09/16 10:34, Adrian Turjak wrote: > That commit doesn't really address the problem in question though. > > Th

[openstack-dev] [osc][keystone] User Project List

I'm running into what doesn't really seem like a sensible design choice around how 'openstack project list' handles the user filter. Because of this here: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/project.py#L199 and because of the find_resource

[openstack-dev] [Keystone] Project name DB length

with. Cheers, Adrian Turjak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Project name DB length

ory textbook for > this one. I imagine that trying to not bloat the token was definitely > a concern. IIRC User name was 64 also, but we had to increase to 255 > because we're not in control of name that comes from external sources > (like LDAP). > > On Wed, Sep 28, 2016 at 11:06 PM,

[openstack-dev] [Horizon] Rework Access & Security panel

n Access & Security make sense, but floating ips really shouldn't be there. If there aren't any arguments against it, I can put together a blueprint/patch for this myself, but would like to know people are happy with the change. Any alternate ideas? Vehement opposition to the change? Cheers, A

Re: [openstack-dev] [Horizon] Rework Access & Security panel

On 27/10/16 15:11, Adrian Turjak wrote: > seems usual and rather confusing UX. s/usual/unusual/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On 09/11/16 11:12, Gage Hugo wrote: > This spec was discussed at the keystone meeting today and during the > conversation that continued afterwards, an idea of using the keystone > configuration to set a list of keys was mentioned. > > The idea is that a cloud admin could define a list of keys

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

On 06/11/16 13:17, Steve Martinelli wrote: > > Interesting, I'll add this to the review and see how some if the folks > proposing the new APIs would find that as suitable for their use > cases. For reference: http://developer.openstack.org/api-ref/compute/ For our use case, I need key:value

Re: [openstack-dev] [osc] bug/design flaw: Clients not cached per region

On 18/10/16 03:36, Dean Troyer wrote: > On Sun, Oct 16, 2016 at 9:11 PM, Adrian Turjak > <adri...@catalyst.net.nz <mailto:adri...@catalyst.net.nz>> wrote: > > The problem I'm running into is for some of our custom plugins we > require the commands t

Re: [openstack-dev] [osc] bug/design flaw: Clients not cached per region

On 18/10/16 15:15, Adrian Turjak wrote: > Although option would be to leave the cache in osc-lib untouched as a > pure singleton and just make a new one for openstackclient that does > support regions. odd typo. "Although anothe

Re: [openstack-dev] [osc] bug/design flaw: Clients not cached per region

On 18/10/16 14:09, Dean Troyer wrote: > On Mon, Oct 17, 2016 at 5:29 PM, Adrian Turjak <adri...@catalyst.net.nz> > wrote: >> What I'm wondering is can the current client cache be changed to be keyed >> off the client_manager.region_name? That way the change is on

Re: [openstack-dev] [osc] bug/design flaw: Clients not cached per region

On 18/10/16 15:52, Jamie Lennox wrote: > > A comment from the cheap seats, almost all clients are using a > keystoneauth1 session at this point and that's where your > authentication information is being cached. There is essentially no > cost to creating a client with an existing session as auth

Re: [openstack-dev] [Keystone] Project name DB length

On 21/10/16 04:30, Adam Young wrote: > > No. keep them short. We are working toward a scheme where you can > nest the names like this" > > > parent/child1/child2 > > > But if you make them too long, that becomes a disaster. There is a > strict option in the config file that prevents you from

Re: [openstack-dev] [osc] bug/design flaw: Clients not cached per region

In response to Jamie's comment I've abandoned my patch in favor of this one: https://review.openstack.org/#/c/388232 It simply removes the ClientCache from the openstackclient code and replaces it with property(). On 18/10/16 17:10, Adrian Turjak wrote: > > On 18/10/16 15:52, Jamie

[openstack-dev] [Keystone][Horizon] Additional MFA option: per user ip address rules

). Any thoughts? Cheers, Adrian Turjak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

On 04/11/16 01:16, Julien Danjou wrote: > On Thu, Nov 03 2016, Adrian Turjak wrote: > >> I'd need to double check exactly what query it is, but it effectively >> amounts to: >> "List all instance metric samples where project_id is and timestamp >> is in

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

On 03/11/16 03:01, gordon chung wrote: > gnocchi captures the state of a resource and it's history. this is > accessible by looking at resource history. i'm not entirely sure if that > handles your case, may you could provide the queries you use and we > could figure out equivalent gnocchi

Re: [openstack-dev] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

Been vaguely following this thread and I have a question. Just to confirm, as I haven't touched ceilometer code in ages, the instance metric still exists? Or at least something like it? We're currently using ceilometer as the data collection for our billing, and the instance metric is our

[openstack-dev] [osc] bug/design flaw: Clients not cached per region

to list your instances across all regions could be quite useful and easy to do. Any thoughts? Suggestions? Cheers, Adrian Turjak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ

Re: [openstack-dev] [keystone] Custom ProjectID upon creation

Just to clarify, the reason you want custom project IDs is so that when you create a project in one region, you can create it again with the same ID in another? Isn't that just manual replication though? What happens when there are projects in only one region? Or if that isn't meant to happen,

Re: [openstack-dev] [keystone] Custom ProjectID upon creation

On 06/12/16 12:15, Andrey Grebennikov wrote: > > Just to clarify, the reason you want custom project IDs is so that > when you create a project in one region, you can create it again > with the same ID in another? Isn't that just manual replication > though? > > What happens

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

This actually sounds a lot like a domain per reseller, with a sub-domain per reseller customer. With the reseller themselves probably also running a sub-domain or two for themselves. Mayb even running their own external federated user system for that specific reseller domain.That or something like

Re: [openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

ty to have "hidden" projects or not in the subtree. > > However, we can always improve! Please submit a spec where we > will be able to discuss in further detail the options we have > to improve the current UX of the HMT feature :) > > On

[openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

, but it also feels like so many of the features are a little half-baked. :( Anyone with some insight into this and is there any interest in making subtree listing more flexible/useful? Cheers, Adrian Turjak Further reading: https://github.com/openstack/keystone-specs/blob/master/specs/keystone/kilo

[openstack-dev] [Neutron] Security Worries about Network RBAC

this feature safer in Neutron? Will we get the support to make it happen? Or should we just develop something around it so it works for us as we need it to? It's a very useful feature, but as it stands it's too unsafe to expose in a public cloud environment. Regards, Adrian Turjak

Re: [openstack-dev] [Neutron] Security Worries about Network RBAC

en see keystone alterations when they happen so it would require constant background polling.1. https://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancementsCheers,Kevin BentonOn Tue, Feb 28, 2017 at 7:43 PM, Adrian Turjak <adri...@cataly

Re: [openstack-dev] [Neutron] Security Worries about Network RBAC

Bug/RFE is up! https://bugs.launchpad.net/neutron/+bug/1669630 Hopefully that sums of what I'm ideally after well enough, and is useful to the greater community and project as a whole. Cheers, Adrian Turjak On 01/03/17 22:00, Adrian Turjak wrote: > Hello Kevin, > > Thanks for t

Re: [openstack-dev] [horizon] [horizon-plugin] Raising Django version cap

rocess of adding a > non-voting job for 1.11 right now, so we should be able to move quickly. > > Rob > >> On 5 Jul 2017, at 01:36, Adrian Turjak <adri...@catalyst.net.nz >> <mailto:adri...@catalyst.net.nz>> wrote: >> >> Great work! >> >>

Re: [openstack-dev] [horizon] [horizon-plugin] Raising Django version cap

Great work! Is there anything that can be done to help meet that July deadline and get 1.11.x in? I'm more than happy to help with reviews or even fixes for newer Django in Horizon, and we should try and get others involved if it will help as I think this is a little urgent. Running anything

Re: [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

On 03/05/17 01:23, Monty Taylor wrote: > On 05/02/2017 12:11 AM, Adrian Turjak wrote: >> Hello OpenStack folks, >> >> As part of my dev work I recently put together a cool little tool which >> lets me have much easier access to the various OpenStack python clients

Re: [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

On 04/05/17 03:20, Dean Troyer wrote: > On Mon, May 1, 2017 at 11:11 PM, Adrian Turjak <adri...@catalyst.net.nz> > wrote: >> As part of my dev work I recently put together a cool little tool which >> lets me have much easier access to the various OpenStack python

Re: [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

On 04/05/17 03:32, Dean Troyer wrote: > On Tue, May 2, 2017 at 7:32 PM, Adrian Turjak <adri...@catalyst.net.nz> wrote: >> Shade in this context is both really easy, and harder since I can't just >> give it the same session so it can reuse the same token. I've tried >

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 17/05/17 23:20, Sean Dague wrote: > On 05/16/2017 07:34 PM, Adrian Turjak wrote: > >> Anyway that aside, I'm sold on API keys as a concept in this case >> provided they are project owned rather than user owned, I just don't >> think we should make them too unique, an

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 14:00, Adrian Turjak wrote: > > On 16/05/17 13:29, Lance Bragstad wrote: >> >> >> On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak >> <adri...@catalyst.net.nz <mailto:adri...@catalyst.net.nz>> wrote: >> >> >> On 16/05/17

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 13:29, Lance Bragstad wrote: > > > On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak > <adri...@catalyst.net.nz <mailto:adri...@catalyst.net.nz>> wrote: > > > On 16/05/17 01:09, Lance Bragstad wrote: >> >> >> On Sun,

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 01:09, Lance Bragstad wrote: > > > On Sun, May 14, 2017 at 11:59 AM, Monty Taylor > wrote: > > On 05/11/2017 02:32 PM, Lance Bragstad wrote: > > Hey all, > > One of the Baremetal/VM sessions at the summit focused

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 16:13, Colleen Murphy wrote: > On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak > <adri...@catalyst.net.nz <mailto:adri...@catalyst.net.nz>> wrote: > > > > Tangentially related to this (because my reasons are different), > on our cloud I'm a

Re: [openstack-dev] [keystone] deprecating the policy and credential APIs

So I've actually been using the credentials API for some of my work towards MFA, different types of MFA, and even different stages for MFA. For example (totp in this case), I first have a service create a user's totp secret as type 'totp-draft' so that the totp auth method can't use it, but so

Re: [openstack-dev] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On 25/05/17 07:47, Lance Bragstad wrote: > *Option 2* > > Implement global role assignments in keystone. > / > / > /How it works:/ > / > / > Role assignments in keystone can be scoped to global context. Users > can then ask for a globally scoped token > > Pros: > - This approach represents a

Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

On 19 May 2017 11:43 am, Curtis <serverasc...@gmail.com> wrote:On Thu, May 18, 2017 at 4:13 PM, Adrian Turjak <adri...@catalyst.net.nz> wrote: > Hello fellow OpenStackers, > > For the last while I've been looking at options for multi-region > multi-master Keystone,

[openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

this, because I'm hoping this is the solution I've been hoping to find for quite a long time. Further reading: https://www.cockroachlabs.com/ https://github.com/cockroachdb/cockroach https://www.cockroachlabs.com/docs/build-a-python-app-with-cockroachdb-sqlalchemy.html Cheers, - Adrian Turjak

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 22:39, Sean Dague wrote: > On 05/15/2017 10:00 PM, Adrian Turjak wrote: >> I'm well aware of the policy work, and it is fantastic to see it >> progressing! I can't wait to actually be able to play with that stuff! >> We've been painstakingly tweaking the js

[openstack-dev] [Keystone][PublicCloud] Introducing Adjutant, an OpenStack service for signups, user invites, password reset and more!

and maturity to achieve as a project, but we're running it in production (an older state at least, with newer coming soon) and it will only get better in time. If this sounds interesting to you, get in touch, try it out, get involved! Cheers, Adrian Turjak

[openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

is welcome! Cheers, Adrian Turjak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo

Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

On 20/05/17 09:31, Mike Bayer wrote: > > On 05/18/2017 06:13 PM, Adrian Turjak wrote: >> >> So, specifically in the realm of Keystone, since we are using sqlalchemy >> we already have Postgresql support, and since Cockroachdb does talk >> Postgres it shouldn'

[openstack-dev] [keystone] Does the policy.json for trusts works?

Hello Keystone devs! I've been playing with some policy changes and realised that the trust policy rules were mostly blank. Which, based on how the policy logic works means that any authed user can list trusts:

Re: [openstack-dev] [keystone] Does the policy.json for trusts works?

default we'd add. On 16/09/17 13:09, Boris Bobrov wrote: > Hi, > > On 13.09.2017 18:54, Adrian Turjak wrote: >> Hello Keystone devs! >> >> I've been playing with some policy changes and realised that the trust >> policy rules were mostly blank. Which, based on ho

[openstack-dev] [Swift][Keystone] Swift vs Keystone permission models

Hello fellow openstackers, I'm trying to figure something out that confuses me around how Swift handles roles from Keystone, and what the ACLs allow. In the Swift config you can specify roles which can manage the containers for their project ('operator_roles'), and anyone with such a role

Re: [openstack-dev] [all] Switching to longer development cycles

I worry that moving to a yearly release is actually going to make things worse for deployers and there will be less encouragement for them to be on more up to date and bug fixed code. Not to mention, no one will trust or use the intermediary releases unless they are coordinated and tested much

Re: [openstack-dev] [keystone] multiple federated keystones with single Identity Provider

On 08/12/17 11:47, Lance Bragstad wrote: > > On 12/07/2017 12:27 PM, Colleen Murphy wrote: >> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy >> wrote: >>> Hi all, >>> >>> We have a following use case - several independent keystones (say KeyA and >>> KeyB),

Re: [openstack-dev] [Openstack-operators] [publiccloud-wg][keystone][Horizon] Multi-Factor Auth in OpenStack

On 09/02/18 15:50, Lance Bragstad wrote: > On 02/08/2018 03:36 PM, Adrian Turjak wrote: >> My plan for the Rocky cycle is to work in Keystone and address the missing >> pieces I need to get MFA working properly throughout OpenStack in an >> actually useful way, and

[openstack-dev] [adjutant] [PTL] [Election] PTL candidacy for the Stein cycle

potentially help with. :) Cheers, Adrian Turjak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 6 August 2018

Bah! I saw this while on holiday and didn't get a chance to respond, sorry for being late to the conversation. On 11/08/18 3:46 AM, Colleen Murphy wrote: > ### Self-Service Keystone > > At the weekly meeting Adam suggested we make self-service keystone a focus > point of the PTG[9]. Currently,

Re: [openstack-dev] [all][tc][release][election][adjutant] Welcome Adjutant as an official project!

Thanks! As the current project lead for Adjutant I welcome the news, and while I know it wasn't an easy process would like to thank everyone involved in the voting. All the feedback (good and bad) will be taken on board to make the service as suited for OpenStack as possible in the space we've

[openstack-dev] [keystone][adjutant] Sync with adjutant team

As I'm not attending the PTG, I thought I might help put some words against these questions for when you're having the meeting. Plus even if I did want to be online, it would be something like 4am my time. Stein will likely see a lot of Adjutant refactor work as I get myself back onto the project

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

8 at 5:02 AM Juan Antonio Osorio Robles > mailto:jaosor...@redhat.com>> wrote: > > FWIW, instead of barbican, castellan could be used as a key manager. > > > On 08/30/2018 12:23 PM, Adrian Turjak wrote: >> >> >> On 30/08/18 6:

Re: [openstack-dev] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

Adjutant should be should be good to go. I don't believe there are any blockers (unless I've missed some). On 31/08/18 11:24 AM, Doug Hellmann wrote: > Below is the list of project teams that have not yet started migrating > their zuul configuration. If you're ready to go, please respond to this

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

current plan for our deployment of Barbican is per region. Is that the norm? Because if so, then it kind of means using it for Keystone becomes less useful. On 31/08/18 12:02 PM, Adrian Turjak wrote: > > Oh I was literally just thinking about the 'credential' type key value > items

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

On 30/08/18 6:29 AM, Lance Bragstad wrote: > > Is that what is being described here ?  > > https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html > > > This is a separate mechanism for storing secrets, not necessarily > passwords (although I agree the term

[openstack-dev] [publiccloud-wg] [adjutant] Input on Adjutant's official project status

ions about the service, don't hesitate to get in touch, but some input on the current discussion would be very welcome! Cheers, Adrian Turjak pEpkey.asc Description: application/pgp-keys __ OpenStack Development Ma

[openstack-dev] [Keystone] Weirdness around domain/project scope in role assignments

Sooo to follow up from the discussion last night partly with Lance and Adam, I'm still not exactly sure what difference, if any, there is between a domain scoped role assignment, and a project scoped role assignment. And... It appears stuff breaks when you used both, or either actually (more on

[openstack-dev] Proposal: The OpenStack Client Library Guide

Hello fellow OpenStackers, As some of you have probably heard me rant, I've been thinking about how to better solve the problem with various tools that support OpenStack or are meant to be OpenStack clients/tools which don't always work as expected by those of us directly in the community.

[openstack-dev] [all] How to handle python3 only projects

encourage new projects to be python3 only (if not require it)? It's not an easy topic, and there are likely lots of opinions on the matter, but it's something to start considering. Cheers! - Adrian Turjak __ OpenStack

Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update

On 20/10/18 4:09 AM, Matt Riedemann wrote: > The big news this week is we have a couple of volunteer developers > from NEC (Akhil Jain and Rajat Dhasmana) who are pushing the base > framework changes across a lot of the projects [1]. I'm trying to > review as many of these as I can. The request

Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update

On 24/10/18 2:09 AM, Ben Nemec wrote: > > > On 10/22/18 5:40 PM, Matt Riedemann wrote: >> On 10/22/2018 4:35 PM, Adrian Turjak wrote: >>>> The one other open question I have is about the Adjutant change [2]. I >>>> know Adjutant is very new a

[openstack-dev] [keystone] noop role in openstack

For Adam's benefit continuing this a bit in email: regarding the noop role: http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-20.log.html#t2018-09-20T04:13:43 The first benefit of such a role (in the given policy scenario) is that you can now give a user