Re: [Openstack-operators] Delegating quota management for all projects to a user without the admin role?

[Tim Bell]

I think you could do something with policy.json to define which operations a 
given role would have access to. We have used this to provide the centre 
operator with abilities such as stop/start. The technical details are described 
at https://openstack-in-production.blogspot.fr/2015/02/delegation-of-roles.html.

Tim

From: "Edmund Rhudy (BLOOMBERG/ 120 PARK)" 
Reply-To: Edmund Rhudy 
Date: Friday, 27 January 2017 at 00:36
To: openstack-operators 
Subject: [Openstack-operators] Delegating quota management for all projects to 
a user without the admin role?

I'm looking for a way to allow a user that does not have the admin role to be 
able to view and set quota (both Nova/Cinder) for all projects in an OpenStack 
cluster. For us, the boundary of a Keystone region is coterminous with an 
OpenStack cluster - we don't currently use any sort of federated Keystone.

Background: we are involved in a project (not the Keystone variety) for 
integrating Bloomberg's internal budget processes closely with purchasing 
compute resources. The idea of this system is that you will purchase some 
number of standardized compute units and then you can allocate them to projects 
in various OpenStack clusters as you wish. In order to do this, the tool needs 
to be able to see what Keystone projects you have access to, see how much quota 
that project has, and modify the quota settings for it appropriately.

For obvious reasons, I'd like to keep the API access for this tool to a 
minimum. I know that if all else fails, the goal can be accomplished by giving 
it admin access, so I'm keeping that in my back pocket, but I'd like to exhaust 
all reasonable options first.

Allowing the tool to see project memberships and get project information is 
easy. The quota part, however, is not. I'm not sure how to accomplish that 
delegation, or how to give the tool admin-equivalent access for a very small 
subset of the APIs. I'm unfamiliar with Keystone trusts and am not sure it 
would be appropriate here anyway, because it would seem like I'd need to 
delegate admin control to the role user in order to allow quota get/set. The 
only other thing I can think of, and it seems really off the wall to me, is to:

* create a local domain in Keystone
* create one user in this local domain per every Keystone project and add it to 
that project
* give this user a special role that allows it to set quotas for its project
* set up a massive many-to-one web of trusts where all of these users are 
delegated back to the tool's account

This solution seems very convoluted, and the number of trusts the tool will 
need to know about is going to grow linearly with the number of projects in 
Keystone.

The clusters in question are all running Liberty, with Keystone v3 available. 
Keystone is in a single-domain configuration, where the default domain is 
sourcing users from LDAP and all other information is stored in SQL.

Anyone have any thoughts, or am I SOL and just have to give this thing admin 
access and make sure the creds stay under lock and key?
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] OpenStack Days East Looking for Sponsors & Leads!

[Haisam Ido]

Dear OpenStack Users, Operators, and Community,

We are excited to announce that OpenStack Days
 East 2017 will
be in the city of Washington, DC, with the tentative dates of Aug 15-16,
2017, which are flexible. The two day event will have a focus on the
Government sector, amongst many others, such as containerization, DevOps
practices, provisioning, orchestration and more.

OpenStackDC , OpenStack-Northern
Virginia , OpenStack-Baltimore
, VA OpenStack Users
, and several other east coast
OpenStack groups will be organizing the OpenStack Days East 2017 event. In
order to proceed in earnest, with the planning, we are soliciting a
tentative sponsorship commitment from your company for this event.

Last year’s sponsorship costs can be found here
,
which may differ in 2017. All sponsorship levels are currently available
for 2017. If your company is interested in sponsoring this conference,
please fill out this form
.
Also, please keep in mind that this initial sponsorship step only requires
a contact name and an email address from your company.

One pivotal element which is necessary in order to ensure the timeliness,
and success of this event is to find a corporate lead. We are seeking a
company or companies that are willing to engage with the OpenStack Days
East organizers, volunteers and committee members to co-plan the event, and
help with the initial seed funding required to reserve a venue, and several
other essentials required for a successful event. If you are interested
please contact us immediately via email, and fill out this form
.


As you know OpenStack Days East , in NYC
 last year, was a resounding
success.  Some of the companies that sponsored the 2016 event were HP
Enterprise, Red Hat, SUSE, Canonical, Dell, and IBM. The full list of 2016
sponsors can be found here . We
look forward to hearing back from you soon. Thank you very much in advance.

Thank you very much in advance and we look forward to working with you.

Best Regards,

Haisam Ido , OpenStackDC
 Organizer

Shilla Saebi ,
OpenStack-Northern
Virginia  Organizer

James Genus 
Jr., OpenStack-Baltimore 
Organizer

Trevor Lowing , VA OpenStack Users
 Organizer
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Delegating quota management for all projects to a user without the admin role?

[Edmund Rhudy (BLOOMBERG/ 120 PARK)]

I'm looking for a way to allow a user that does not have the admin role to be 
able to view and set quota (both Nova/Cinder) for all projects in an OpenStack 
cluster. For us, the boundary of a Keystone region is coterminous with an 
OpenStack cluster - we don't currently use any sort of federated Keystone.

Background: we are involved in a project (not the Keystone variety) for 
integrating Bloomberg's internal budget processes closely with purchasing 
compute resources. The idea of this system is that you will purchase some 
number of standardized compute units and then you can allocate them to projects 
in various OpenStack clusters as you wish. In order to do this, the tool needs 
to be able to see what Keystone projects you have access to, see how much quota 
that project has, and modify the quota settings for it appropriately.

For obvious reasons, I'd like to keep the API access for this tool to a 
minimum. I know that if all else fails, the goal can be accomplished by giving 
it admin access, so I'm keeping that in my back pocket, but I'd like to exhaust 
all reasonable options first.

Allowing the tool to see project memberships and get project information is 
easy. The quota part, however, is not. I'm not sure how to accomplish that 
delegation, or how to give the tool admin-equivalent access for a very small 
subset of the APIs. I'm unfamiliar with Keystone trusts and am not sure it 
would be appropriate here anyway, because it would seem like I'd need to 
delegate admin control to the role user in order to allow quota get/set. The 
only other thing I can think of, and it seems really off the wall to me, is to:

* create a local domain in Keystone
* create one user in this local domain per every Keystone project and add it to 
that project
* give this user a special role that allows it to set quotas for its project
* set up a massive many-to-one web of trusts where all of these users are 
delegated back to the tool's account

This solution seems very convoluted, and the number of trusts the tool will 
need to know about is going to grow linearly with the number of projects in 
Keystone.

The clusters in question are all running Liberty, with Keystone v3 available. 
Keystone is in a single-domain configuration, where the default domain is 
sourcing users from LDAP and all other information is stored in SQL.

Anyone have any thoughts, or am I SOL and just have to give this thing admin 
access and make sure the creds stay under lock and key?___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] User Committee Elections February 2017

[Shilla Saebi]

Hello Everyone,



You may have already heard the exciting news that the OpenStack Board of
Directors recently approved the User Committee (UC) bylaws and charter
. These
remarkable changes will bring the first elected UC representatives in 2017
and expand the UC to 5 members! Voting for the 2017 UC members will be granted
to the Active User Contributors (AUC).

The
current UC will continue to serve until the elections and continue with a
6-month seat. This initial election will run to determine the other two
members. Candidates ranking 1st and 2nd place will get one-year seats. In
the fall of 2017, elections will see the normal renewal of 3 seats for a
one-year period.



Open candidacy for the UC positions will be from January 30 - February 10,
05:59 UTC. Voting for the 2017 User Committee (UC) members will be
open on February
13th and will remain open until February 17, 11:59 UTC. Additional details
and the process for nomination can be found here
.



As a reminder, please see the community code of conduct (
http://www.openstack.org/legal/community-code-of-conduct/)



Please let me, or anyone from the UC know if you have any questions,
comments or concerns.



Thank you,



OpenStack User Committee

Shilla, Edgar, Jonathan
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [keystone] Field 'domain_id' doesn't have a default value

[Eduardo Gonzalez]

Hi.
I’m testing upgrades from Newton to master branch using keystone’s
zero-downtime upgrade method:

keystone-manage db_sync --expand
keystone-manage db_sync --migrate
keystone-manage db_sync --contract

After upgrade is made with no errors in logs, I cannot create users. Other
keystone commands works fine.

Error message: “Field ‘domain_id’ doesn’t have a default value”

Full trace:

2017-01-26 15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters
[req-576e5683-6631-49b9-b532-65f06a23bbeb
4b3ff53812734e72b5aea42103349571 04fe68cf58724855a2ee67781a14b446 -
default default] DBAPIError exception wrapped from
(pymysql.err.InternalError) (1364, u"Field 'domain_id' doesn't have a
default value") [SQL: u'INSERT INTO user (id, enabled, extra,
default_project_id, created_at, last_active_at) VALUES (%(id)s,
%(enabled)s, %(extra)s, %(default_project_id)s, %(created_at)s,
%(last_active_at)s)'] [parameters: {'last_active_at': None, 'extra':
'{}', 'created_at': datetime.datetime(2017, 1, 26, 15, 32, 10,
974903), 'enabled': 1, 'default_project_id': None, 'id':
'8989be945c954f14a1c9ebaf45988fad'}]2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters Traceback (most recent call
last):2017-01-26 15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters
 File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
line 1139, in _execute_context2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters context)2017-01-26 15:32:10.978 17
ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/sqlalchemy/engine/default.py",
line 450, in do_execute2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters cursor.execute(statement,
parameters)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/cursors.py",
line 167, in execute2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters result =
self._query(query)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/cursors.py",
line 323, in _query2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters conn.query(q)2017-01-26
15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 836, in query2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters self._affected_rows =
self._read_query_result(unbuffered=unbuffered)2017-01-26 15:32:10.978
17 ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 1020, in _read_query_result2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters result.read()2017-01-26
15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 1303, in read2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters first_packet =
self.connection._read_packet()2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 982, in _read_packet2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters packet.check_error()2017-01-26
15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 394, in check_error2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters
err.raise_mysql_exception(self._data)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/err.py", line
120, in raise_mysql_exception2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters
_check_mysql_exception(errinfo)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/err.py", line
115, in _check_mysql_exception2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters raise InternalError(errno,
errorvalue)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters InternalError: (1364, u"Field
'domain_id' doesn't have a default value")2017-01-26 15:32:10.978 17
ERROR oslo_db.sqlalchemy.exc_filters

Database migration logs:

2017-01-26 15:27:11.425 18 INFO migrate.versioning.api [-] 4 -> 5...
2017-01-26 15:27:11.540 18 INFO migrate.versioning.api [-]
done2017-01-26 15:27:11.540 18 INFO migrate.versioning.api [-] 5 ->
6... 2017-01-26 15:27:11.643 18 INFO migrate.versioning.api [-]
done2017-01-26 15:27:11.645 18 INFO migrate.versioning.api [-] 6 ->
7... 2017-01-26 15:27:11.758 18 INFO migrate.versioning.api [-]
done2017-01-26 15:27:11.759 18 INFO migrate.versioning.api [-] 7 ->
8... 2017-01-26 15:27:11.872 18 INFO migrate.versioning.api [-]
done2017-01-26 15:27:11.879 18 INFO migrate.versioning.api [-] 8 ->
9... 2017-01-26 15:27:12.082 18 INFO 

[Openstack-operators] Ops Midcycle - Seating Limited Reserve Your Spot!

[Melvin Hillsman]

Good day everyone,

 

We have been hard at work planning another great Ops Mid-cycle! Seating is 
limited so you will want to rush over to - 
https://opsmidcycle_march2017.eventbrite.com - to reserve your spot.

 

Also, we still want your feedback on the sessions and we need your +1s. We are 
in the process of writing the agenda and therefore it is very important you get 
your vote in now on a session or two or all. You can find the planning etherpad 
here - https://etherpad.openstack.org/p/MIL-ops-meetup

 

REMEMBER! Even if you are not attending in person, you can still vote! We want 
to hear from you.

 

***Note***: This event assumes OpenStack ops knowledge and is _not_ appropriate 
for beginners, or a place to learn about OpenStack. The event contains 
relatively few 'presentations' and is mostly a discussion-style event. To find 
other OpenStack events in your area, please visit www.openstack.org/events.

 

Kind regards,

--

Melvin Hillsman
Ops Technical LeadOpenStack Innovation Center
 
mrhillsman@gmail.comphone: (210) 312-1267mobile: (210) 413-1659Learner | 
Ideation | Belief | Responsibility | Command
http://osic.org

 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Neutron] Prefer local Neutron nodes?

[Saverio Proto]

Hello Adam,

this feature you describe makes sense only if the tenant VMs are also
aggregated in the same rack. Is this your scenario ?

Given that you could have 3 network nodes running the L3-agent, then
you can make some scripting to stick the specific router (linux
namespace) to the specific l3-agent.

To see an example of how to migrate a router to a specific l3-agent
please look at:
https://github.com/openstack/osops-tools-contrib/blob/master/neutron/l3-agent-evacuate.py

Saverio


2017-01-25 20:00 GMT+01:00 Adam Lawson :
> Hey everyone,
>
> If we want to implement multiple dedicated neutron routers in multiple racks
> (same cloud), is there a means of which I'm unaware that forces instances to
> route cross-tenant and public traffic to a neutron node within the local
> rack as opposed to load balancing L3 across all neutron nodes in all racks?
>
> Example:
> 6 racks,3 dedicated Neutron nodes per rack
>
> //adam
>
> Adam Lawson
>
> Principal Architect, CEO
> Office: +1-916-794-5706
>
> ___
> 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] [openstack-dev] [openstack-ansible] Live migration issue

[Andy McCrae]

Hi Fabrice,

Firstly, I've moved this over to the ops mailing list (dev in bcc - just so
anybody following along knows where it's gone!) - I think it's more of an
operational issue than a dev one.

That does seem weird - so the error is:


> 2017-01-25 11:03:58.475 113231 ERROR nova.virt.libvirt.driver
> [req-7bd352bf-8818-4f71-9fa0-04fabccebf9c 0329776bd1634978a7fed35a70c77479
> 7531f209e3514e3f98eb58aafa480285 - - -] [instance:
> c7a5e5d1-bc22-4143-a85a-ee5c3b6777b3] Live Migration failure: Requested
> operation is not valid: domain 'instance-0187' is already active
> > 2017-01-25 11:03:58.817 113231 ERROR nova.virt.libvirt.driver
> [req-7bd352bf-8818-4f71-9fa0-04fabccebf9c 0329776bd1634978a7fed35a70c77479
> 7531f209e3514e3f98eb58aafa480285 - - -] [instance:
> c7a5e5d1-bc22-4143-a85a-ee5c3b6777b3] Migration operation has aborted
>

I'm not too sure what could cause this issue, especially only one way -
however here are a few things you could look into if you haven't already:

You might get more info looking in the libvirt error logs, since that's a
libvirt error.
As a "hammer" approach grep in /var/log/libvirt on the compute hosts for
"instance-0187" - that may give a bit more insight.
There should also be instance specific logs there - for example the qemu
ones would be in /var/log/libvirt/qemu/instance-x.log - pretty sure kvm has
similar logs.

I'd say the settings from an OSA perspective are correct since it worked
fine from compute2 --> 1. If you look in the conf files is anything
different that stands out?

Did you try migrate the same instance after it had successfully migrated?
Is this consistent, so if you spun up a new instance on compute 1 and tried
to migrate it to compute 2 it wouldn't work, but any that new instances
that you setup on compute 2 migrate perfectly fine to compute1?

That's a good start I think, hopefully we can help narrow this down!
Andy
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators