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 and I'm no

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 no

[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

[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] [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 > it

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

> On Thu, Aug 30, 2018 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: >> >> &g

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 cred

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, po

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

tors could 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.o

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 dec

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

Features If you have any questions 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-dev] [all] How to handle python3 only projects

avily 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-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. Mostly

[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 tha

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 I'l

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 like

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), using fernet tokens and synchronize

[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 appears

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

ch the new 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. Whi

[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: https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L137-L1

Re: [openstack-dev] [keystone][nova] Persistent application credentials

On 19/07/17 01:23, Colleen Murphy wrote: > On Tue, Jul 18, 2017 at 1:39 AM, Zane Bitter > wrote: > > So the application credentials spec has merged - huge thanks to > Monty and the Keystone team for getting this done: > > https://review.openstack.org/#/c/45

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

pen bugs. I’m in the process 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 > <mailto:adri...@catalyst.net.nz>> wrote: >> >> Great work! >> >> Is there any

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 less

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

ap ranging from larger architectural improvements, useful features, to minor but useful tweaks. It still has a bunch of growth and maturity to achieve as a project, but we're running it in production (an older state at least, with newer coming soon)

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 tha

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 mo

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't b

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

On 19 May 2017 11:43 am, Curtis wrote:On Thu, May 18, 2017 at 4:13 PM, Adrian Turjak wrote: > Hello fellow OpenStackers, > > For the last while I've been looking at options for multi-region > multi-master Keystone, as well as multi-master for other services I've > been

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

kely to do some tests at some stage regarding 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-a

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

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 tweak

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 > mailto:adri...@catalyst.net.nz>> wrote: > > > > Tangentially related to this (because my reasons are different), > on our cloud I'm actually working on somethin

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 >> mailto:adri...@catalyst.net.nz>> wrote: >> >> >> On 16/05/17 01:09, Lance Bragstad wrote: &

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 > mailto:adri...@catalyst.net.nz>> wrote: > > > On 16/05/17 01:09, Lance Bragstad wrote: >> >> >> On Sun, May 14, 2017 at 11:59 AM, Monty Tayl

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 on what > we ne

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 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 >> seeing if I can pilfe

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 > 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 clients >> in the scope of a py

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

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

eedback 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/mailma

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

This sounds like a fantastic​ path forward as the version in the service​ type is a source​ of frustration in some ways. I personally love the version​less discoverability of Keystone as an API model.I'm also assuming this is related to this repo here:https://github.com/openstack/service-types-auth

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

ove - it is basically a choice between the > possibility 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 im

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

interesting, and potentially very useful, 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/k

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

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

on). We also have no framework in place to even 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

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

but gives us as deployers far more safety and security. So, what to do? Is it worth trying to make 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 use

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

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. The b

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

split is very helpful no matter from performance > 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 > mailto:adri...@cat

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 https://blueprints.launchpad.net/horizon/+spec/

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 wh

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, how

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

(or even run your own local Horizon so it uses your ip). Any thoughts? Cheers, Adrian Turjak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject

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 th

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 pairin

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 quer

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 primary

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.

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

emaining resources in 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 opposi

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 ma

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:

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 h

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 another o

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 > 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 only in how the >> clients are

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 > mailto:adri...@catalyst.net.nz>> wrote: > > The problem I'm running into is for some of our custom plugins we > require the commands to run in all regions. We do this by get

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

in clouds.yaml could be very useful. A command 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 fo

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

t the history 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

[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] [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 > mailto:adri...@catalyst.net.nz>> wrote: > > - or update "openstack project list" with a "--auth-user" flag > that ignores all other options and direct

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. > > The probl

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 t

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

at 12:31 AM Adrian Turjak 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 this specific failure and the corresponding policy? As far as

[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 ca

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

ject: Re: [openstack-dev] [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 fantast

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

cally 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: OpenStack Development M

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] [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? > https://github.com/openstack/keyst

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 > 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 TOTP stored in the > keyston

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

martinelli@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 dec

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

nsible solution to MFA 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...@l

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

il me 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/lis

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 "E

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

abel is "User Name" 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 0

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

pt change, only 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

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

Typo fix, see below. On 16/01/15 12:26, Adrian Turjak wrote: > Hello David, > > We are definitely assessing the option, although even switching Keystone > to be backed by an LDAP service might also work, and not be a switch to > a fully federated system. I believe Keystone has h

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

s, let > me know > > regards > > David > > On 15/01/2015 00:42, Morgan Fainberg wrote: >>> >>> On Jan 13, 2015, at 9:06 PM, Adrian Turjak wrote: >>> >>> Hello openstack-dev, >>> >>> I'm wondering if there is any inte

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

omplexity at present, 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 key

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 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 enough work force to

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 int

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

or billing. I don't 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

[openstack-dev] [Ceilometer]Cumulative metrics resetting

ss_notification' function 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

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] Issues with transformers

, where should I start to look 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 ___