Re: [Openstack-operators] Granular roles and policy.json modifications
On 04/02/16 05:51, Michael Richardson wrote: Hi all, Is anyone using granular roles or groups, with fewer permissions granted than _member_ ? If so, have you found a nice, simple (within the context of OpenStack) method or scheme for:- a) modifying the default "admin_or_owner" rules, which would otherwise match any role as long as the tenant is correct, b) handling the ubiquitous empty rules, (e.g. "":""), which also allow a free pass, if reached. By way of background, at the Mitaka Summit a call was made [0] for operators to record changes they were making to their policy files. Most of the examples given [1] are either for roles with permissions elevated above _member_ (e.g. ProjectAdmin), or where the wider permissions also granted (e.g. by a) and b), above) would not be a concern. Cheers, Michael Just wanted to chime in and say, maybe this should be on the agenda of the upcoming ops meetup as well ... ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Draft Agenda for MAN Ops Meetup (Feb 15, 16)
Hi all, We still need moderators for the following: * Upgrade challenges, LTS releases, patches and packaging * Keystone Federation - discussion session * Post-Puppet deployment patterns - discussion * HA at the Hypervisor level * OSOps - what is it, where is it going, what you can do * OSOps working session Have a look at the moderator's guide @ https://wiki.openstack.org/wiki/Operations/Meetups#Moderators_Guide and let us know if you're interested! Regards, Tom On 01/02/16 17:29, Matt Jarvis wrote: That's a very good point ! OK, so the ones we definitely don't seem to have anyone moderating or presenting against currently are : Tokyo Highlights - going to assume this was a talk Keystone Federation - discussion session Post-Puppet deployment patterns - discussion HA at the Hypervisor level - assume this was a talk too Ceph integration - discussion Writing User Stories - working group OSOps - what is it, where is it going, what you can do OSOps working session Monitoring and Tools WG These were almost all taken from the original etherpad ( https://etherpad.openstack.org/p/MAN-ops-meetup ), so if you suggested them or would like to present/moderate then let us know. If you would like to help with moderating any of the other sessions apart from those above, let us know - for most of the sessions we can always use two moderators. On 1 February 2016 at 09:20, Shamail Tahir mailto:itzsham...@gmail.com>> wrote: Hi Matt, On Mon, Feb 1, 2016 at 3:47 AM, Matt Jarvis mailto:matt.jar...@datacentred.co.uk>> wrote: Hello All The event in Manchester is rapidly approaching, and we're still looking for moderators and presenters for some of these sessions. If you proposed one of the sessions currently in the schedule, please let us know so we can assign you in the schedule. If you'd be willing to help out and moderate one or more sessions, we'd really appreciate your help. Thanks to everyone who's volunteered so far ! How can we identify which sessions are missing moderators currently? On 20 January 2016 at 17:54, Tom Fifield mailto:t...@openstack.org>> wrote: Hi all, Matt, Nick and myself took some time to take our suggestions from the etherpad and attempted to wrangle them into something that would fit in the space we have over 2 days. As a reminder, we have two different kind of sessions - General Sessions, which are discussions for the operator community aimed to produce actions (eg best practices, feedback on badness), and**Working groups**focus on specific topics aiming to make concrete progress on tasks in that area. As always, some stuff has been munged and mangled in an attempt to fit it in so please take a look at the below and reply with your comments! Is anything missing? Something look like a terrible idea? Want to completely change the room layout? There's still a little bit of flexibility at this stage. Day 1 Room 1 Room 2 Room 3 9:00 - 10:00Registration 10:00 - 10:30 Introduction + History of Ops Meetups + Intro to working groups 10:30 - 11:15 How to engage with the community 11:15 - 11:20 Breakout explanation 11:20 - 12:00 Tokyo highlightsKeystone and Federation 12:00 - 13:30 Lunch 13:30 - 14:10 Upgrade challenges, LTS releases, patches and packaging Experience with Puppet Deployments HPC / Scientific WG 14:10 - 14:50 Upgrade challenges, LTS releases, patches and packaging Post-Puppet deployment patterns HPC / Scientific WG 14:50 - 15:20 Coffee 15:20 - 16:00 Neutron Operational best practices HA at the Hypervisor level 16:00 - 16:40 OSOps - what is it, where is it going, what you can do OpenStack Ansible Project Update 16:40 - 17:00 Breakout Reports 17:00 - 18:00 Arch Show and Tell 18.00 - Drinks and pizza event Day 2 Room 1 Room 2 Room 3 9:00 - 09:45UX priorities for development - what's broken for you ? GUI, CLI, API 9:45 - 10:30Integrations - billing, signups 10:30 - 11:15 Nov
Re: [Openstack-operators] DVR and public IP consumption
Carl Baldwin writes: > You're right, the IP in the fip namespace doesn't ever get written in > to any packets or used as an arp destination. It is currently > meaningless. That will change with BGP's capability to routed DVR > traffic in Mitaka because that IP will be used as a next hop. > However, it still doesn't need to be a public IP. The routed networks > work that I'm doing in Newton will allow us to eventually make these > private IPs instead of public so that public IPs are not wasted. > > I've given these things a lot of thought but haven't had time to > pursue any such thoughts yet except to implement routed networks as > groundwork. Here are a few old links [1][2] but they are really out > of date. I need to write another spec following the first routed > networks spec explaining how these things will work. > > Here is an etherpad [3] that I put together a couple of years ago > trying to compare different approaches to getting rid of centralized > SNAT too. We just never got any traction on any of these approaches. > Also, without the routed networks work in Newton, many of them are > difficult to accomplish. > > Let me know if anything resonates with you. We might be in a better > position to do some of this work when routed networks is under way. > For example, one thing that routed networks may allow is using private > IPs for the router's address. I think that was in one of the above > blueprints somewhere. Let me go write a new spec and post it. I'll > update this thread when I've got it up. > > Carl > > [1] https://review.openstack.org/#/c/174657/2/specs/liberty/eliminate-dvr-fip-ns.rst > [2] https://review.openstack.org/#/c/175517/1/specs/liberty/no-router-ip.rst > [3] https://etherpad.openstack.org/p/decentralized-snat > Hi Carl, sorry for the late reply, but these links of yours expanded to about 12 tabs in my browser, most with serveral pages of text. "Given lots of thought" may be an understatement. Both the specs sound very resonable to me. The second one is exactly what I was saying here before. (Evidently I was not the first.) Why was it not accepted? It seems quite easy to implement in contrast to full routed networks. The work on routed networks will be beneficial mainly for large deployments, whose needs exceed the capacity of a few L2 domains. Small public deployers are working on the scale of tens of boxes, but hundreds of tenants. Each tenant gets a virtual router, which eats an IP. I only have 1024 IPs from RIPE and will probably get no more. If most of the tenants are small and only use a one or two VMs, I'm wasting up to 50% addresses and it is severely limiting my growth potential. I do not really understand why routed networks would be a prerequisite to using private IPs for router interfaces. I'm aiming at the last point from the Etherpad - Carrier grade NAT. Do you think that I could use the "Allow setting a tenant router's external IP" function and disable any checks if the specified IP is in the network defined as external? I already have a private subnet on the same L2 segment, that is NATted by the datacenter routers. The API is admin-only, so it would not create a risk. I would pre-create a router for each tenant and everyone would be happy. Floating IPs are taken care of at the compute nodes in DVR. Tomas ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Help with horizon and v3 auth
Hey everyone, In my liberty testing, I've got keystone v3 setup, and everything seems to work, except certain cinder functions Using openstack client, I can boot an instance from image to a new volume. Using horizon, this fails. I have followed the v3 guides, having setup local_settings to have OPENSTACK_API_VERSION with 'identity': 3, and also having the /v3 endpoint. The logs indicate that horizon can't find the tenant id. When I saw this using the CLI, the fix was to add the 'endpoint_template' substituting "tenant_id" with "project_id" Does anyone know of any additional changes needed to make horizon work with auth v3 backend? signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Granular roles and policy.json modifications
> On 04/02/16 05:51, Michael Richardson wrote: >> Hi all, >> >> Is anyone using granular roles or groups, with fewer permissions granted >> than >> _member_ ? If so, have you found a nice, simple (within the context of >> OpenStack) method or scheme for:- >> >> a) modifying the default "admin_or_owner" rules, which would otherwise >> match >> any role as long as the tenant is correct, >> b) handling the ubiquitous empty rules, (e.g. "":""), which also >> allow a >> free pass, if reached. >> >> By way of background, at the Mitaka Summit a call was made [0] for >> operators >> to record changes they were making to their policy files. Most of the >> examples given [1] are either for roles with permissions elevated above >> _member_ (e.g. ProjectAdmin), or where the wider permissions also >> granted >> (e.g. by a) and b), above) would not be a concern. >> >> Cheers, >> Michael > > On Fri, February 5, 2016 12:26 am, Tom Fifield wrote: > Just wanted to chime in and say, maybe this should be on the agenda of > the upcoming ops meetup as well ... That would be brilliant. Regrettably, it'll be difficult for me to be there in person, though IRC and etherpads travel well. On a related note, https://review.openstack.org/#/c/245629 may help to some degree (in the fullness of time!). -- Michael Richardson Catalyst IT Limited ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
