Re: [Openstack-operators] How to allow users to list services by modifying the policy.json file of Keystone
On 01/26/2015 04:02 PM, Fischer, Matt wrote: Is there any reason that the user can¹t just run keystone catalog which does not require admin permissions? Matt, this is just an example. We tried it with different list methods and it is also not working. We read your blog post about the topic (http://www.mattfischer.com/blog/?p=524) and it is working for us for services like Neutron or Nova. But not for Keystone. Christian. -- Christian Berendt Cloud Solution Architect Mail: bere...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] :document an OpenStack production environment
In my earlier days I had tried many formal schemes, but it always cause problems. For now I settle to following scheme: machine-used database (dns, chef, etc) for explit details like mac addresses, hardware, rack location, network communication. That database should be constantly used, not 'write only', otherwise everyone will starts to forget to update, and suddenly it will loose it authority over 'I wrote you about it in hipchat and than send you update via sms, and final version is in your other skype account'. Usually it some kind of 'work', or 'control panel', or chef data bags. All topological schemes should be hand written. Whiteboards is just perfect for that. Why? Because all tools, except pen/pencil/marker are restrain you, forcing to use terminology and linking type of that tool. Even inkscape is restricting, because you can not just 'undersubscribe' link, or draw funny spiral (here it goes somewhere...). And text in corporate wiki in free form. Yes, updates will change everything, but even after updates original picture and text will be precious, because they will say history and will help to debug strange issues with historical reasons. Corporate blogs are perfect place for updates and ideas for future update. Yes, it is a mess, but it is better than 'not enough information because of the format restrictions'. On 01/26/2015 03:45 PM, matt wrote: I really liked using sphinx for documentation back in the day, it has the benefit of being community compatible. I also enjoyed graphviz integration in sphinx for diagrams... and then there was templating gnuplots but i think I was probably considered a masochist on this front. at the very least management types did not like that they couldn't really edit our documentation. -matt On Mon, Jan 26, 2015 at 5:10 AM, George Shuklin george.shuk...@gmail.com mailto:george.shuk...@gmail.com wrote: We using chef to manage hosts. Data bags contains all data of all hosts. We keep hardware configuration and DC-wide-name in databags too. For the flowcharts we mostly use markers and whiteboard, sometime I sketch stuff in dia [1] or with wacom tablet in mypaint. [1] http://sourceforge.net/projects/dia-installer/ On 01/25/2015 04:15 PM, Daniel Comnea wrote: Hi all, Can anyone who runs Openstack in a production environment/ data center share how you document the whole infrastructure, what tools are used for drawing diagrams(i guess you need some pictures otherwise is hard to understand it :)), maybe even an inventory etc? Thanks, Dani P.S in the past - 10+ - i used to have maintain a red book but i suspect situation is different in 2015 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org mailto:OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org mailto:OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] How to allow users to list services by modifying the policy.json file of Keystone
Is there any reason that the user can¹t just run keystone catalog which
does not require admin permissions?
On 1/26/15, 4:58 AM, Christian Berendt bere...@b1-systems.de wrote:
Hello.
We have an user 'user1' in the tenant 'tenant1' with the assigned role
'_member_'.
We want to be able to list services with this user. In the default
policy.json files we can find the following rules:
admin_required: role:admin or is_admin:1,
identity:list_services: rule:admin_required,
As expected 'keystone service-list' will fail with a HTTP error 403
('admin_required').
Now we change the rule admin_required to
admin_required: role:_member_ or role:admin or is_admin:1.
As expected 'keystone service-list' is now working. But we want to be
able to only list services, with this modification of the admin_required
rule it is possible to list e.g. roles, too.
We undo the change to admin_required and change identity:list_services to
identity:list_services: rule:admin_required or role:_member_,
'keystone service-list' will fail with an HTTP error 403
('admin_required').
We change identity:list_services to
identity:list_services: role:_member_,
'keystone service-list' will fail with an HTTP error 403
('admin_required').
We change identity:list_services to
identity:list_services: @,
'keystone service-list' will fail with an HTTP error 403
('admin_required').
It looks like the modifications of identity:list_services are ignored.
Any idea what we are doing wrong?
Christian.
--
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] :document an OpenStack production environment
i wish hp would open source their cmdb code... that stuff was pretty neat. On Mon, Jan 26, 2015 at 10:03 AM, George Shuklin george.shuk...@gmail.com wrote: In my earlier days I had tried many formal schemes, but it always cause problems. For now I settle to following scheme: machine-used database (dns, chef, etc) for explit details like mac addresses, hardware, rack location, network communication. That database should be constantly used, not 'write only', otherwise everyone will starts to forget to update, and suddenly it will loose it authority over 'I wrote you about it in hipchat and than send you update via sms, and final version is in your other skype account'. Usually it some kind of 'work', or 'control panel', or chef data bags. All topological schemes should be hand written. Whiteboards is just perfect for that. Why? Because all tools, except pen/pencil/marker are restrain you, forcing to use terminology and linking type of that tool. Even inkscape is restricting, because you can not just 'undersubscribe' link, or draw funny spiral (here it goes somewhere...). And text in corporate wiki in free form. Yes, updates will change everything, but even after updates original picture and text will be precious, because they will say history and will help to debug strange issues with historical reasons. Corporate blogs are perfect place for updates and ideas for future update. Yes, it is a mess, but it is better than 'not enough information because of the format restrictions'. On 01/26/2015 03:45 PM, matt wrote: I really liked using sphinx for documentation back in the day, it has the benefit of being community compatible. I also enjoyed graphviz integration in sphinx for diagrams... and then there was templating gnuplots but i think I was probably considered a masochist on this front. at the very least management types did not like that they couldn't really edit our documentation. -matt On Mon, Jan 26, 2015 at 5:10 AM, George Shuklin george.shuk...@gmail.com wrote: We using chef to manage hosts. Data bags contains all data of all hosts. We keep hardware configuration and DC-wide-name in databags too. For the flowcharts we mostly use markers and whiteboard, sometime I sketch stuff in dia [1] or with wacom tablet in mypaint. [1] http://sourceforge.net/projects/dia-installer/ On 01/25/2015 04:15 PM, Daniel Comnea wrote: Hi all, Can anyone who runs Openstack in a production environment/ data center share how you document the whole infrastructure, what tools are used for drawing diagrams(i guess you need some pictures otherwise is hard to understand it :)), maybe even an inventory etc? Thanks, Dani P.S in the past - 10+ - i used to have maintain a red book but i suspect situation is different in 2015 ___ OpenStack-operators mailing listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] :document an OpenStack production environment
I use LibreOffice Draw for architecture diagrams. VRT Network Equipment [2] pretty much blows everything out of the water. For text documentation that I manually create (chef for example does this automatically) I'll put in plaintext files per environment that includes basic stuff such as hostname, IP, and server function. On 2015-01-25 09:15, Daniel Comnea wrote: Hi all, Can anyone who runs Openstack in a production environment/ data center share how you document the whole infrastructure, what tools are used for drawing diagrams(i guess you need some pictures otherwise is hard to understand it :)), maybe even an inventory etc? Thanks, Dani P.S in the past - 10+ - i used to have maintain a red book but i suspect situation is different in 2015 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators [1] Links: -- [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators [2] http://extensions.libreoffice.org/extension-center/vrt-network-equipment ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Mar 9-10, 2015, Philadelphia, USA - Next Ops Meetup
On 1/23/15 4:55 AM, Tom Fifield wrote: On 22/01/15 14:36, Mathieu Gagné wrote: On 2015-01-12 12:11 AM, Tom Fifield wrote: Yup - standby for registration. Most likely some time this week. Any update? I would like to know the schedule to plan my return flight accordingly. http://www.eventbrite.com/e/openstack-ops-mid-cycle-meetup-tickets-15319934336 better announcement soon :) Thanks Tom! Are there any details regarding hotel accommodations? -- -jlk ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] :document an OpenStack production environment
Excellent input, please keep it going. Maybe someone from HP will shed more light on their cmdb? Dani On Mon, Jan 26, 2015 at 4:28 PM, j j...@no-io.net wrote: I use LibreOffice Draw for architecture diagrams. VRT Network Equipment http://extensions.libreoffice.org/extension-center/vrt-network-equipment pretty much blows everything out of the water. For text documentation that I manually create (chef for example does this automatically) I'll put in plaintext files per environment that includes basic stuff such as hostname, IP, and server function. On 2015-01-25 09:15, Daniel Comnea wrote: Hi all, Can anyone who runs Openstack in a production environment/ data center share how you document the whole infrastructure, what tools are used for drawing diagrams(i guess you need some pictures otherwise is hard to understand it :)), maybe even an inventory etc? Thanks, Dani P.S in the past - 10+ - i used to have maintain a red book but i suspect situation is different in 2015 ___ OpenStack-operators mailing listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Instance creation boot from image (creates a new volume) is Slow
You might get faster performance if the image was in raw format in glance. On Friday, January 23, 2015, Pedro Sousa pgso...@gmail.com wrote: Hi all, I have a swift backend to store my glance images and a EMC storage to store my volumes. When I try to boot the instance directly from the volume, the process is slow. I understand that glance has to convert the image from swift and copy it to the volume but is there a way to speedup this? Also If I try to more than 4 instances at one using this process it will eventually timeout and I will have instances in ERROR state. Thanks, Pedro Sousa ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] :document an OpenStack production environment
We using chef to manage hosts. Data bags contains all data of all hosts. We keep hardware configuration and DC-wide-name in databags too. For the flowcharts we mostly use markers and whiteboard, sometime I sketch stuff in dia [1] or with wacom tablet in mypaint. [1] http://sourceforge.net/projects/dia-installer/ On 01/25/2015 04:15 PM, Daniel Comnea wrote: Hi all, Can anyone who runs Openstack in a production environment/ data center share how you document the whole infrastructure, what tools are used for drawing diagrams(i guess you need some pictures otherwise is hard to understand it :)), maybe even an inventory etc? Thanks, Dani P.S in the past - 10+ - i used to have maintain a red book but i suspect situation is different in 2015 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] How to allow users to list services by modifying the policy.json file of Keystone
Hello.
We have an user 'user1' in the tenant 'tenant1' with the assigned role
'_member_'.
We want to be able to list services with this user. In the default
policy.json files we can find the following rules:
admin_required: role:admin or is_admin:1,
identity:list_services: rule:admin_required,
As expected 'keystone service-list' will fail with a HTTP error 403
('admin_required').
Now we change the rule admin_required to
admin_required: role:_member_ or role:admin or is_admin:1.
As expected 'keystone service-list' is now working. But we want to be
able to only list services, with this modification of the admin_required
rule it is possible to list e.g. roles, too.
We undo the change to admin_required and change identity:list_services to
identity:list_services: rule:admin_required or role:_member_,
'keystone service-list' will fail with an HTTP error 403 ('admin_required').
We change identity:list_services to
identity:list_services: role:_member_,
'keystone service-list' will fail with an HTTP error 403 ('admin_required').
We change identity:list_services to
identity:list_services: @,
'keystone service-list' will fail with an HTTP error 403 ('admin_required').
It looks like the modifications of identity:list_services are ignored.
Any idea what we are doing wrong?
Christian.
--
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Mar 9-10, 2015, Philadelphia, USA - Next Ops Meetup
On 27/01/15 05:38, Jesse Keating wrote: On 1/23/15 4:55 AM, Tom Fifield wrote: On 22/01/15 14:36, Mathieu Gagné wrote: On 2015-01-12 12:11 AM, Tom Fifield wrote: Yup - standby for registration. Most likely some time this week. Any update? I would like to know the schedule to plan my return flight accordingly. http://www.eventbrite.com/e/openstack-ops-mid-cycle-meetup-tickets-15319934336 better announcement soon :) Thanks Tom! Are there any details regarding hotel accommodations? I believe our friends at Comcast have secured a room block at the Four Seasons with a preferred rate. The current plan is to email people who register details of that, but I guess a prod to eve...@openstack.org can't hurt if anyone needs it sooner :) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Mar 9-10, 2015, Philadelphia, USA - Next Ops Meetup
Thanks Tom! Are there any details regarding hotel accommodations? It's not official, but several us from Time Warner Cable are staying at http://www.thewindsorsuites.com/ which appears to be fairly close and reasonably priced for the area. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
