[Openstack-operators] OpenStack-operators Digest, Vol 96, Issue 7
Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]
michael.d.moore at nasa.gov
Sat Oct 20 23:15:16 UTC 2018
The images exist and are bootable. I'm going to trace through the actual code for glance API. Any suggestions on where the show/hide logic is when it filters responses? I'm new to digging through OpenStack code.
________________________________
From: Logan Hicks [logan.hicks at live.com]
Sent: Friday, October 19, 2018 8:00 PM
To: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] OpenStack-operators Digest, Vol 96, Issue 7
Re: Glance Image Visibility Issue? - Non admin users can see
private images from other tenants (Chris Apsey)
I noticed that the image says queued. If Im not mistaken, an image cant have permissions applied until after the image is created, which might explain the issue hes seeing.
The object doesnt exist until its made by openstack.
Id check to see if something is holding up images being made. Id start with glance.
Respectfully,
Logan Hicks
-------- Original message --------
From: openstack-operators-request at lists.openstack.org
Date: 10/19/18 7:49 PM (GMT-05:00)
To: openstack-operators at lists.openstack.org
Subject: OpenStack-operators Digest, Vol 96, Issue 7
Send OpenStack-operators mailing list submissions to
openstack-operators at lists.openstack.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
or, via email, send a message with subject or body 'help' to
openstack-operators-request at lists.openstack.org
You can reach the person managing the list at
openstack-operators-owner at lists.openstack.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-operators digest..."
Today's Topics:
1. [nova] Removing the CachingScheduler (Matt Riedemann)
2. Re: Glance Image Visibility Issue? - Non admin users can see
private images from other tenants
(Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.])
3. Re: Glance Image Visibility Issue? - Non admin users can see
private images from other tenants (Chris Apsey)
4. Re: Glance Image Visibility Issue? - Non admin users can see
private images from other tenants (iain MacDonnell)
5. Re: Glance Image Visibility Issue? - Non admin users can see
private images from other tenants
(Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.])
6. Re: Glance Image Visibility Issue? - Non admin users can see
private images from other tenants (iain MacDonnell)
7. Re: Glance Image Visibility Issue? - Non admin users can see
private images from other tenants (Chris Apsey)
8. osops-tools-monitoring Dependency problems (Tomáš Vondra)
9. [heat][cinder] How to create stack snapshot including volumes
(Christian Zunker)
10. Fleio - OpenStack billing - ver. 1.1 released (Adrian Andreias)
11. Re: [Openstack-sigs] [all] Naming the T release of OpenStack
(Tony Breeds)
12. Re: Glance Image Visibility Issue? - Non admin users can see
private images from other tenants
(Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.])
13. Re: Glance Image Visibility Issue? - Non admin users can see
private images from other tenants
(Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.])
14. Re: Fleio - OpenStack billing - ver. 1.1 released (Jay Pipes)
15. Re: Fleio - OpenStack billing - ver. 1.1 released (Mohammed Naser)
16. [Octavia] SSL errors polling amphorae and missing tenant
network interface (Erik McCormick)
17. Re: [Octavia] SSL errors polling amphorae and missing tenant
network interface (Gaël THEROND)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Oct 2018 17:07:00 -0500
From: Matt Riedemann <mriedemos at gmail.com>
To: "openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>
Subject: [Openstack-operators] [nova] Removing the CachingScheduler
Message-ID: <fa0c5339-a54d-6720-ca10-7f0cff12dba1 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
It's been deprecated since Pike, and the time has come to remove it [1].
mgagne has been the most vocal CachingScheduler operator I know and he
has tested out the "nova-manage placement heal_allocations" CLI, added
in Rocky, and said it will work for migrating his deployment from the
CachingScheduler to the FilterScheduler + Placement.
If you are using the CachingScheduler and have a problem with its
removal, now is the time to speak up or forever hold your peace.
[1] https://review.openstack.org/#/c/611723/1
--
Thanks,
Matt
------------------------------
Message: 2
Date: Thu, 18 Oct 2018 22:11:40 +0000
From: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"
<michael.d.moore at nasa.gov>
To: iain MacDonnell <iain.macdonnell at oracle.com>,
"openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -
Non admin users can see private images from other tenants
Message-ID: <EDBAEC2C-5245-4952-86C9-CDC635667C92 at nasa.gov>
Content-Type: text/plain; charset="utf-8"
I have replicated this unexpected behavior in a Pike test environment, in addition to our Queens environment.
Mike Moore, M.S.S.E.
Systems Engineer, Goddard Private Cloud
Michael.D.Moore at nasa.gov
Hydrogen fusion brightens my day.
On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore at nasa.gov> wrote:
Yes. I verified it by creating a non-admin user in a different tenant. I created a new image, set to private with the project defined as our admin tenant.
In the database I can see that the image is 'private' and the owner is the ID of the admin tenant.
Mike Moore, M.S.S.E.
Systems Engineer, Goddard Private Cloud
Michael.D.Moore at nasa.gov
Hydrogen fusion brightens my day.
On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
INTEGRA, INC.] wrote:
> I’m seeing unexpected behavior in our Queens environment related to
> Glance image visibility. Specifically users who, based on my
> understanding of the visibility and ownership fields, should NOT be able
> to see or view the image.
>
> If I create a new image with openstack image create and specify –project
> <tenant> and –private a non-admin user in a different tenant can see and
> boot that image.
>
> That seems to be the opposite of what should happen. Any ideas?
Yep, something's not right there.
Are you sure that the user that can see the image doesn't have the admin
role (for the project in its keystone token) ?
Did you verify that the image's owner is what you intended, and that the
visibility really is "private" ?
~iain
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
------------------------------
Message: 3
Date: Thu, 18 Oct 2018 18:23:35 -0400
From: Chris Apsey <bitskrieg at bitskrieg.net>
To: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"
<michael.d.moore at nasa.gov>, iain MacDonnell
<iain.macdonnell at oracle.com>,
<openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -
Non admin users can see private images from other tenants
Message-ID:
<1668946da70.278c.5f0d7f2baa7831a2bbe6450f254d9a24 at bitskrieg.net>
Content-Type: text/plain; format=flowed; charset="UTF-8"
Do you have a liberal/custom policy.json that perhaps is causing unexpected
behavior? Can't seem to reproduce this.
On October 18, 2018 18:13:22 "Moore, Michael Dane (GSFC-720.0)[BUSINESS
INTEGRA, INC.]" <michael.d.moore at nasa.gov> wrote:
> I have replicated this unexpected behavior in a Pike test environment, in
> addition to our Queens environment.
>
>
>
> Mike Moore, M.S.S.E.
>
> Systems Engineer, Goddard Private Cloud
> Michael.D.Moore at nasa.gov
>
> Hydrogen fusion brightens my day.
>
>
> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA,
> INC.]" <michael.d.moore at nasa.gov> wrote:
>
> Yes. I verified it by creating a non-admin user in a different tenant. I
> created a new image, set to private with the project defined as our admin
> tenant.
>
> In the database I can see that the image is 'private' and the owner is the
> ID of the admin tenant.
>
> Mike Moore, M.S.S.E.
>
> Systems Engineer, Goddard Private Cloud
> Michael.D.Moore at nasa.gov
>
> Hydrogen fusion brightens my day.
>
>
> On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>
>
>
> On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
> INTEGRA, INC.] wrote:
>> I’m seeing unexpected behavior in our Queens environment related to
>> Glance image visibility. Specifically users who, based on my
>> understanding of the visibility and ownership fields, should NOT be able
>> to see or view the image.
>>
>> If I create a new image with openstack image create and specify –project
>> <tenant> and –private a non-admin user in a different tenant can see and
>> boot that image.
>>
>> That seems to be the opposite of what should happen. Any ideas?
>
> Yep, something's not right there.
>
> Are you sure that the user that can see the image doesn't have the admin
> role (for the project in its keystone token) ?
>
> Did you verify that the image's owner is what you intended, and that the
> visibility really is "private" ?
>
> ~iain
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
------------------------------
Message: 4
Date: Thu, 18 Oct 2018 15:25:22 -0700
From: iain MacDonnell <iain.macdonnell at oracle.com>
To: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"
<michael.d.moore at nasa.gov>, "openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -
Non admin users can see private images from other tenants
Message-ID: <11e3f7a6-875e-4b6c-259a-147188a860e1 at oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
I suspect that your non-admin user is not really non-admin. How did you
create it?
What you have for "context_is_admin" in glance's policy.json ?
~iain
On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
INTEGRA, INC.] wrote:
> I have replicated this unexpected behavior in a Pike test environment, in addition to our Queens environment.
>
>
>
> Mike Moore, M.S.S.E.
>
> Systems Engineer, Goddard Private Cloud
> Michael.D.Moore at nasa.gov
>
> Hydrogen fusion brightens my day.
>
>
> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore at nasa.gov> wrote:
>
> Yes. I verified it by creating a non-admin user in a different tenant. I created a new image, set to private with the project defined as our admin tenant.
>
> In the database I can see that the image is 'private' and the owner is the ID of the admin tenant.
>
> Mike Moore, M.S.S.E.
>
> Systems Engineer, Goddard Private Cloud
> Michael.D.Moore at nasa.gov
>
> Hydrogen fusion brightens my day.
>
>
> On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>
>
>
> On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
> INTEGRA, INC.] wrote:
> > I’m seeing unexpected behavior in our Queens environment related to
> > Glance image visibility. Specifically users who, based on my
> > understanding of the visibility and ownership fields, should NOT be able
> > to see or view the image.
> >
> > If I create a new image with openstack image create and specify –project
> > <tenant> and –private a non-admin user in a different tenant can see and
> > boot that image.
> >
> > That seems to be the opposite of what should happen. Any ideas?
>
> Yep, something's not right there.
>
> Are you sure that the user that can see the image doesn't have the admin
> role (for the project in its keystone token) ?
>
> Did you verify that the image's owner is what you intended, and that the
> visibility really is "private" ?
>
> ~iain
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>
>
------------------------------
Message: 5
Date: Thu, 18 Oct 2018 22:32:42 +0000
From: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"
<michael.d.moore at nasa.gov>
To: iain MacDonnell <iain.macdonnell at oracle.com>,
"openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -
Non admin users can see private images from other tenants
Message-ID: <44085CC4-899C-49B2-9934-0800F6650B0B at nasa.gov>
Content-Type: text/plain; charset="utf-8"
openstack user create --domain default --password xxxxxxxx --project-domain ndc --project test mike
openstack role add --user mike --user-domain default --project test user
my admin account is in the NDC domain with a different username.
/etc/glance/policy.json
{
"context_is_admin": "role:admin",
"default": "role:admin",
<snip>
I'm not terribly familiar with the policies but I feel like that default line is making everyone an admin by default?
Mike Moore, M.S.S.E.
Systems Engineer, Goddard Private Cloud
Michael.D.Moore at nasa.gov
Hydrogen fusion brightens my day.
On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
I suspect that your non-admin user is not really non-admin. How did you
create it?
What you have for "context_is_admin" in glance's policy.json ?
~iain
On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
INTEGRA, INC.] wrote:
> I have replicated this unexpected behavior in a Pike test environment, in addition to our Queens environment.
>
>
>
> Mike Moore, M.S.S.E.
>
> Systems Engineer, Goddard Private Cloud
> Michael.D.Moore at nasa.gov
>
> Hydrogen fusion brightens my day.
>
>
> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore at nasa.gov> wrote:
>
> Yes. I verified it by creating a non-admin user in a different tenant. I created a new image, set to private with the project defined as our admin tenant.
>
> In the database I can see that the image is 'private' and the owner is the ID of the admin tenant.
>
> Mike Moore, M.S.S.E.
>
> Systems Engineer, Goddard Private Cloud
> Michael.D.Moore at nasa.gov
>
> Hydrogen fusion brightens my day.
>
>
> On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>
>
>
> On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
> INTEGRA, INC.] wrote:
> > I’m seeing unexpected behavior in our Queens environment related to
> > Glance image visibility. Specifically users who, based on my
> > understanding of the visibility and ownership fields, should NOT be able
> > to see or view the image.
> >
> > If I create a new image with openstack image create and specify –project
> > <tenant> and –private a non-admin user in a different tenant can see and
> > boot that image.
> >
> > That seems to be the opposite of what should happen. Any ideas?
>
> Yep, something's not right there.
>
> Are you sure that the user that can see the image doesn't have the admin
> role (for the project in its keystone token) ?
>
> Did you verify that the image's owner is what you intended, and that the
> visibility really is "private" ?
>
> ~iain
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>
>
------------------------------
Message: 6
Date: Thu, 18 Oct 2018 15:48:27 -0700
From: iain MacDonnell <iain.macdonnell at oracle.com>
To: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"
<michael.d.moore at nasa.gov>, "openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -
Non admin users can see private images from other tenants
Message-ID: <c8bb19c1-8dcb-7f68-db3e-199cefd5c442 at oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
That all looks fine.
I believe that the "default" policy applies in place of any that's not
explicitly specified - i.e. "if there's no matching policy below, you
need to have the admin role to be able to do it". I do have that line in
my policy.json, and I cannot reproduce your problem (see below).
I'm not using domains (other than "default"). I wonder if that's a factor...
~iain
$ openstack user create --password foo user1
+---------------------+----------------------------------+
| Field | Value |
+---------------------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | d18c0031ec56430499a2d690cb1f125c |
| name | user1 |
| options | {} |
| password_expires_at | None |
+---------------------+----------------------------------+
$ openstack user create --password foo user2
+---------------------+----------------------------------+
| Field | Value |
+---------------------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | be9f1061a5104abd834eabe98dff055d |
| name | user2 |
| options | {} |
| password_expires_at | None |
+---------------------+----------------------------------+
$ openstack project create project1
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | |
| domain_id | default |
| enabled | True |
| id | 826876d6d3724018bae6253c7f540cb3 |
| is_domain | False |
| name | project1 |
| parent_id | default |
| tags | [] |
+-------------+----------------------------------+
$ openstack project create project2
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | |
| domain_id | default |
| enabled | True |
| id | b446b93ac6e24d538c1943acbdd13cb2 |
| is_domain | False |
| name | project2 |
| parent_id | default |
| tags | [] |
+-------------+----------------------------------+
$ openstack role add --user user1 --project project1 _member_
$ openstack role add --user user2 --project project2 _member_
$ export OS_PASSWORD=foo
$ export OS_USERNAME=user1
$ export OS_PROJECT_NAME=project1
$ openstack image list
+--------------------------------------+--------+--------+
| ID | Name | Status |
+--------------------------------------+--------+--------+
| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
+--------------------------------------+--------+--------+
$ openstack image create --private image1
+------------------+------------------------------------------------------------------------------+
| Field | Value
|
+------------------+------------------------------------------------------------------------------+
| checksum | None
|
| container_format | bare
|
| created_at | 2018-10-18T22:17:41Z
|
| disk_format | raw
|
| file |
/v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file
|
| id | 6a0c1928-b79c-4dbf-a9c9-305b599056e4
|
| min_disk | 0
|
| min_ram | 0
|
| name | image1
|
| owner | 826876d6d3724018bae6253c7f540cb3
|
| properties | locations='[]', os_hash_algo='None',
os_hash_value='None', os_hidden='False' |
| protected | False
|
| schema | /v2/schemas/image
|
| size | None
|
| status | queued
|
| tags |
|
| updated_at | 2018-10-18T22:17:41Z
|
| virtual_size | None
|
| visibility | private
|
+------------------+------------------------------------------------------------------------------+
$ openstack image list
+--------------------------------------+--------+--------+
| ID | Name | Status |
+--------------------------------------+--------+--------+
| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
| 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |
+--------------------------------------+--------+--------+
$ export OS_USERNAME=user2
$ export OS_PROJECT_NAME=project2
$ openstack image list
+--------------------------------------+--------+--------+
| ID | Name | Status |
+--------------------------------------+--------+--------+
| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
+--------------------------------------+--------+--------+
$ export OS_USERNAME=admin
$ export OS_PROJECT_NAME=admin
$ export OS_PASSWORD=xxx
$ openstack image set --public 6a0c1928-b79c-4dbf-a9c9-305b599056e4
$ export OS_USERNAME=user2
$ export OS_PROJECT_NAME=project2
$ export OS_PASSWORD=foo
$ openstack image list
+--------------------------------------+--------+--------+
| ID | Name | Status |
+--------------------------------------+--------+--------+
| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
| 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |
+--------------------------------------+--------+--------+
$
On 10/18/2018 03:32 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
INTEGRA, INC.] wrote:
> openstack user create --domain default --password xxxxxxxx --project-domain ndc --project test mike
>
>
> openstack role add --user mike --user-domain default --project test user
>
> my admin account is in the NDC domain with a different username.
>
>
>
> /etc/glance/policy.json
> {
>
> "context_is_admin": "role:admin",
> "default": "role:admin",
>
> <snip>
>
>
> I'm not terribly familiar with the policies but I feel like that default line is making everyone an admin by default?
>
>
> Mike Moore, M.S.S.E.
>
> Systems Engineer, Goddard Private Cloud
> Michael.D.Moore at nasa.gov
>
> Hydrogen fusion brightens my day.
>
>
> On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>
>
> I suspect that your non-admin user is not really non-admin. How did you
> create it?
>
> What you have for "context_is_admin" in glance's policy.json ?
>
> ~iain
>
>
> On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
> INTEGRA, INC.] wrote:
> > I have replicated this unexpected behavior in a Pike test environment, in addition to our Queens environment.
> >
> >
> >
> > Mike Moore, M.S.S.E.
> >
> > Systems Engineer, Goddard Private Cloud
> > Michael.D.Moore at nasa.gov
> >
> > Hydrogen fusion brightens my day.
> >
> >
> > On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore at nasa.gov> wrote:
> >
> > Yes. I verified it by creating a non-admin user in a different tenant. I created a new image, set to private with the project defined as our admin tenant.
> >
> > In the database I can see that the image is 'private' and the owner is the ID of the admin tenant.
> >
> > Mike Moore, M.S.S.E.
> >
> > Systems Engineer, Goddard Private Cloud
> > Michael.D.Moore at nasa.gov
> >
> > Hydrogen fusion brightens my day.
> >
> >
> > On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
> >
> >
> >
> > On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
> > INTEGRA, INC.] wrote:
> > > I’m seeing unexpected behavior in our Queens environment related to
> > > Glance image visibility. Specifically users who, based on my
> > > understanding of the visibility and ownership fields, should NOT be able
> > > to see or view the image.
> > >
> > > If I create a new image with openstack image create and specify –project
> > > <tenant> and –private a non-admin user in a different tenant can see and
> > > boot that image.
> > >
> > > That seems to be the opposite of what should happen. Any ideas?
> >
> > Yep, something's not right there.
> >
> > Are you sure that the user that can see the image doesn't have the admin
> > role (for the project in its keystone token) ?
> >
> > Did you verify that the image's owner is what you intended, and that the
> > visibility really is "private" ?
> >
> > ~iain
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
> >
> >
>
>
------------------------------
Message: 7
Date: Thu, 18 Oct 2018 19:23:42 -0400
From: Chris Apsey <bitskrieg at bitskrieg.net>
To: iain MacDonnell <iain.macdonnell at oracle.com>, "Moore, Michael Dane
(GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore at nasa.gov>,
<openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -
Non admin users can see private images from other tenants
Message-ID:
<166897de830.278c.5f0d7f2baa7831a2bbe6450f254d9a24 at bitskrieg.net>
Content-Type: text/plain; format=flowed; charset="UTF-8"
We are using multiple keystone domains - still can't reproduce this.
Do you happen to have a customized keystone policy.json?
Worst case, I would launch a devstack of your targeted release. If you
can't reproduce the issue there, you would at least know its caused by a
nonstandard config rather than a bug (or at least not a bug that's present
when using a default config)
On October 18, 2018 18:50:12 iain MacDonnell <iain.macdonnell at oracle.com>
wrote:
> That all looks fine.
>
> I believe that the "default" policy applies in place of any that's not
> explicitly specified - i.e. "if there's no matching policy below, you
> need to have the admin role to be able to do it". I do have that line in
> my policy.json, and I cannot reproduce your problem (see below).
>
> I'm not using domains (other than "default"). I wonder if that's a factor...
>
> ~iain
>
>
> $ openstack user create --password foo user1
> +---------------------+----------------------------------+
> | Field | Value |
> +---------------------+----------------------------------+
> | domain_id | default |
> | enabled | True |
> | id | d18c0031ec56430499a2d690cb1f125c |
> | name | user1 |
> | options | {} |
> | password_expires_at | None |
> +---------------------+----------------------------------+
> $ openstack user create --password foo user2
> +---------------------+----------------------------------+
> | Field | Value |
> +---------------------+----------------------------------+
> | domain_id | default |
> | enabled | True |
> | id | be9f1061a5104abd834eabe98dff055d |
> | name | user2 |
> | options | {} |
> | password_expires_at | None |
> +---------------------+----------------------------------+
> $ openstack project create project1
> +-------------+----------------------------------+
> | Field | Value |
> +-------------+----------------------------------+
> | description | |
> | domain_id | default |
> | enabled | True |
> | id | 826876d6d3724018bae6253c7f540cb3 |
> | is_domain | False |
> | name | project1 |
> | parent_id | default |
> | tags | [] |
> +-------------+----------------------------------+
> $ openstack project create project2
> +-------------+----------------------------------+
> | Field | Value |
> +-------------+----------------------------------+
> | description | |
> | domain_id | default |
> | enabled | True |
> | id | b446b93ac6e24d538c1943acbdd13cb2 |
> | is_domain | False |
> | name | project2 |
> | parent_id | default |
> | tags | [] |
> +-------------+----------------------------------+
> $ openstack role add --user user1 --project project1 _member_
> $ openstack role add --user user2 --project project2 _member_
> $ export OS_PASSWORD=foo
> $ export OS_USERNAME=user1
> $ export OS_PROJECT_NAME=project1
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> +--------------------------------------+--------+--------+
> $ openstack image create --private image1
> +------------------+------------------------------------------------------------------------------+
> | Field | Value
> |
> +------------------+------------------------------------------------------------------------------+
> | checksum | None
> |
> | container_format | bare
> |
> | created_at | 2018-10-18T22:17:41Z
> |
> | disk_format | raw
> |
> | file |
> /v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file
> |
> | id | 6a0c1928-b79c-4dbf-a9c9-305b599056e4
> |
> | min_disk | 0
> |
> | min_ram | 0
> |
> | name | image1
> |
> | owner | 826876d6d3724018bae6253c7f540cb3
> |
> | properties | locations='[]', os_hash_algo='None',
> os_hash_value='None', os_hidden='False' |
> | protected | False
> |
> | schema | /v2/schemas/image
> |
> | size | None
> |
> | status | queued
> |
> | tags |
> |
> | updated_at | 2018-10-18T22:17:41Z
> |
> | virtual_size | None
> |
> | visibility | private
> |
> +------------------+------------------------------------------------------------------------------+
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |
> +--------------------------------------+--------+--------+
> $ export OS_USERNAME=user2
> $ export OS_PROJECT_NAME=project2
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> +--------------------------------------+--------+--------+
> $ export OS_USERNAME=admin
> $ export OS_PROJECT_NAME=admin
> $ export OS_PASSWORD=xxx
> $ openstack image set --public 6a0c1928-b79c-4dbf-a9c9-305b599056e4
> $ export OS_USERNAME=user2
> $ export OS_PROJECT_NAME=project2
> $ export OS_PASSWORD=foo
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |
> +--------------------------------------+--------+--------+
> $
>
>
> On 10/18/2018 03:32 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
> INTEGRA, INC.] wrote:
>> openstack user create --domain default --password xxxxxxxx --project-domain
>> ndc --project test mike
>>
>>
>> openstack role add --user mike --user-domain default --project test user
>>
>> my admin account is in the NDC domain with a different username.
>>
>>
>>
>> /etc/glance/policy.json
>> {
>>
>> "context_is_admin": "role:admin",
>> "default": "role:admin",
>>
>> <snip>
>>
>>
>> I'm not terribly familiar with the policies but I feel like that default
>> line is making everyone an admin by default?
>>
>>
>> Mike Moore, M.S.S.E.
>>
>> Systems Engineer, Goddard Private Cloud
>> Michael.D.Moore at nasa.gov
>>
>> Hydrogen fusion brightens my day.
>>
>>
>> On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>>
>>
>> I suspect that your non-admin user is not really non-admin. How did you
>> create it?
>>
>> What you have for "context_is_admin" in glance's policy.json ?
>>
>> ~iain
>>
>>
>> On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
>> INTEGRA, INC.] wrote:
>>> I have replicated this unexpected behavior in a Pike test environment, in
>>> addition to our Queens environment.
>>>
>>>
>>>
>>> Mike Moore, M.S.S.E.
>>>
>>> Systems Engineer, Goddard Private Cloud
>>> Michael.D.Moore at nasa.gov
>>>
>>> Hydrogen fusion brightens my day.
>>>
>>>
>>> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA,
>>> INC.]" <michael.d.moore at nasa.gov> wrote:
>>>
>>> Yes. I verified it by creating a non-admin user in a different tenant. I
>>> created a new image, set to private with the project defined as our admin
>>> tenant.
>>>
>>> In the database I can see that the image is 'private' and the owner is the
>>> ID of the admin tenant.
>>>
>>> Mike Moore, M.S.S.E.
>>>
>>> Systems Engineer, Goddard Private Cloud
>>> Michael.D.Moore at nasa.gov
>>>
>>> Hydrogen fusion brightens my day.
>>>
>>>
>>> On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>>>
>>>
>>>
>>> On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
>>> INTEGRA, INC.] wrote:
>>> > I’m seeing unexpected behavior in our Queens environment related to
>>> > Glance image visibility. Specifically users who, based on my
>>> > understanding of the visibility and ownership fields, should NOT be able
>>> > to see or view the image.
>>> >
>>> > If I create a new image with openstack image create and specify –project
>>> > <tenant> and –private a non-admin user in a different tenant can see and
>>> > boot that image.
>>> >
>>> > That seems to be the opposite of what should happen. Any ideas?
>>>
>>> Yep, something's not right there.
>>>
>>> Are you sure that the user that can see the image doesn't have the admin
>>> role (for the project in its keystone token) ?
>>>
>>> Did you verify that the image's owner is what you intended, and that the
>>> visibility really is "private" ?
>>>
>>> ~iain
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
------------------------------
Message: 8
Date: Fri, 19 Oct 2018 10:58:30 +0200
From: Tomáš Vondra <vondra at homeatcloud.cz>
To: <OpenStack-operators at lists.openstack.org>
Subject: [Openstack-operators] osops-tools-monitoring Dependency
problems
Message-ID: <049e01d46789$e8bf5220$ba3df660$@homeatcloud.cz>
Content-Type: text/plain; charset="iso-8859-2"
Hi!
I'm a long time user of monitoring-for-openstack, also known as oschecks.
Concretely, I used a version from 2015 with OpenStack python client
libraries from Kilo. Now I have upgraded them to Mitaka and it got broken.
Even the latest oschecks don't work. I didn't quite expect that, given that
there are several commits from this year e.g. by Nagasai Vinaykumar
Kapalavai and paramite. Can one of them or some other user step up and say
what version of OpenStack clients is oschecks working with? Ideally, write
it down in requirements.txt so that it will be reproducible? Also, some
documentation of what is the minimal set of parameters would also come in
handy.
Thanks a lot, Tomas from Homeatcloud
The error messages are as absurd as:
oschecks-check_glance_api --os_auth_url='http://10.1.101.30:5000/v2.0'
--os_username=monitoring --os_password=XXX --os_tenant_name=monitoring
CRITICAL: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/oschecks/utils.py", line 121, in
safe_run
method()
File "/usr/lib/python2.7/dist-packages/oschecks/glance.py", line 29, in
_check_glance_api
glance = utils.Glance()
File "/usr/lib/python2.7/dist-packages/oschecks/utils.py", line 177, in
__init__
self.glance.parser = self.glance.get_base_parser(sys.argv)
TypeError: get_base_parser() takes exactly 1 argument (2 given)
(I can see 4 parameters on the command line.)
------------------------------
Message: 9
Date: Fri, 19 Oct 2018 11:21:25 +0200
From: Christian Zunker <christian.zunker at codecentric.cloud>
To: openstack-operators <openstack-operators at lists.openstack.org>
Subject: [Openstack-operators] [heat][cinder] How to create stack
snapshot including volumes
Message-ID:
<CAHS=D_ZGow+hSPuiicq6z0UrRCb3DxC4hf425uY7+5+Rt+-z5w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi List,
I'd like to take snapshots of heat stacks including the volumes.
>From what I found until now, this should be possible. You just have to
configure some parts of OpenStack.
I enabled cinder-backup with ceph backend. Backups from volumes are working.
I configured heat to include the option backups_enabled = True.
When I use openstack stack snapshot create, I get a snapshot but no backups
of my volumes. I don't get any error messages in heat. Debug logging didn't
help either.
OpenStack version is Pike on Ubuntu installed with openstack-ansible.
heat version is 9.0.3. So this should also include this bugfix:
https://bugs.launchpad.net/heat/+bug/1687006
Is anybody using this feature? What am I missing?
Best regards
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20181019/bb7dd81b/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 19 Oct 2018 12:42:00 +0300
From: Adrian Andreias <adrian at fleio.com>
To: openstack-operators at lists.openstack.org
Subject: [Openstack-operators] Fleio - OpenStack billing - ver. 1.1
released
Message-ID:
<CACp-FE3gEP=nwXRtwy-H13qXrnhPa5bn0uWiukxWp=YTU-4e8A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
We've just released Fleio version 1.1.
Fleio is a billing solution and control panel for OpenStack public clouds
and traditional web hosters.
Fleio software automates the entire process for cloud users. New customers
can use Fleio to sign up for an account, pay invoices, add credit to their
account, as well as create and manage cloud resources such as virtual
machines, storage and networking.
Full feature list:
https://fleio.com#features
You can see an online demo:
https://fleio.com/demo
And sign-up for a free trial:
https://fleio.com/signup
Cheers!
- Adrian Andreias
https://fleio.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20181019/3031e47f/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 19 Oct 2018 20:54:29 +1100
From: Tony Breeds <tony at bakeyournoodle.com>
To: OpenStack Development <openstack-dev at lists.openstack.org>,
OpenStack SIGs <openstack-sigs at lists.openstack.org>, OpenStack
Operators <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] [Openstack-sigs] [all] Naming the T
release of OpenStack
Message-ID: <20181019095428.GA9399 at thor.bakeyournoodle.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Oct 18, 2018 at 05:35:39PM +1100, Tony Breeds wrote:
> Hello all,
> As per [1] the nomination period for names for the T release have
> now closed (actually 3 days ago sorry). The nominated names and any
> qualifying remarks can be seen at2].
>
> Proposed Names
> * Tarryall
> * Teakettle
> * Teller
> * Telluride
> * Thomas
> * Thornton
> * Tiger
> * Tincup
> * Timnath
> * Timber
> * Tiny Town
> * Torreys
> * Trail
> * Trinidad
> * Treasure
> * Troublesome
> * Trussville
> * Turret
> * Tyrone
>
> Proposed Names that do not meet the criteria
> * Train
I have re-worked my openstack/governance change[1] to ask the TC to accept
adding Train to the poll as (partially) described in [2].
I present the names above to the community and Foundation marketing team
for consideration. The list above does contain Train, clearly if the TC
do not approve [1] Train will not be included in the poll when created.
I apologise for any offence or slight caused by my previous email in
this thread. It was well intentioned albeit, with hindsight, poorly
thought through.
Yours Tony.
[1] https://review.openstack.org/#/c/611511/
[2] https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20181019/49c95d5d/attachment-0001.sig>
------------------------------
Message: 12
Date: Fri, 19 Oct 2018 16:33:17 +0000
From: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"
<michael.d.moore at nasa.gov>
To: Chris Apsey <bitskrieg at bitskrieg.net>, iain MacDonnell
<iain.macdonnell at oracle.com>,
"openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -
Non admin users can see private images from other tenants
Message-ID: <4704898B-D193-4540-B106-BF38ACAB68E2 at nasa.gov>
Content-Type: text/plain; charset="utf-8"
Our NDC domain is LDAP backed. Default is not.
Our keystone policy.json file is empty {}
Mike Moore, M.S.S.E.
Systems Engineer, Goddard Private Cloud
Michael.D.Moore at nasa.gov
Hydrogen fusion brightens my day.
On 10/18/18, 7:24 PM, "Chris Apsey" <bitskrieg at bitskrieg.net> wrote:
We are using multiple keystone domains - still can't reproduce this.
Do you happen to have a customized keystone policy.json?
Worst case, I would launch a devstack of your targeted release. If you
can't reproduce the issue there, you would at least know its caused by a
nonstandard config rather than a bug (or at least not a bug that's present
when using a default config)
On October 18, 2018 18:50:12 iain MacDonnell <iain.macdonnell at oracle.com>
wrote:
> That all looks fine.
>
> I believe that the "default" policy applies in place of any that's not
> explicitly specified - i.e. "if there's no matching policy below, you
> need to have the admin role to be able to do it". I do have that line in
> my policy.json, and I cannot reproduce your problem (see below).
>
> I'm not using domains (other than "default"). I wonder if that's a factor...
>
> ~iain
>
>
> $ openstack user create --password foo user1
> +---------------------+----------------------------------+
> | Field | Value |
> +---------------------+----------------------------------+
> | domain_id | default |
> | enabled | True |
> | id | d18c0031ec56430499a2d690cb1f125c |
> | name | user1 |
> | options | {} |
> | password_expires_at | None |
> +---------------------+----------------------------------+
> $ openstack user create --password foo user2
> +---------------------+----------------------------------+
> | Field | Value |
> +---------------------+----------------------------------+
> | domain_id | default |
> | enabled | True |
> | id | be9f1061a5104abd834eabe98dff055d |
> | name | user2 |
> | options | {} |
> | password_expires_at | None |
> +---------------------+----------------------------------+
> $ openstack project create project1
> +-------------+----------------------------------+
> | Field | Value |
> +-------------+----------------------------------+
> | description | |
> | domain_id | default |
> | enabled | True |
> | id | 826876d6d3724018bae6253c7f540cb3 |
> | is_domain | False |
> | name | project1 |
> | parent_id | default |
> | tags | [] |
> +-------------+----------------------------------+
> $ openstack project create project2
> +-------------+----------------------------------+
> | Field | Value |
> +-------------+----------------------------------+
> | description | |
> | domain_id | default |
> | enabled | True |
> | id | b446b93ac6e24d538c1943acbdd13cb2 |
> | is_domain | False |
> | name | project2 |
> | parent_id | default |
> | tags | [] |
> +-------------+----------------------------------+
> $ openstack role add --user user1 --project project1 _member_
> $ openstack role add --user user2 --project project2 _member_
> $ export OS_PASSWORD=foo
> $ export OS_USERNAME=user1
> $ export OS_PROJECT_NAME=project1
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> +--------------------------------------+--------+--------+
> $ openstack image create --private image1
> +------------------+------------------------------------------------------------------------------+
> | Field | Value
> |
> +------------------+------------------------------------------------------------------------------+
> | checksum | None
> |
> | container_format | bare
> |
> | created_at | 2018-10-18T22:17:41Z
> |
> | disk_format | raw
> |
> | file |
> /v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file
> |
> | id | 6a0c1928-b79c-4dbf-a9c9-305b599056e4
> |
> | min_disk | 0
> |
> | min_ram | 0
> |
> | name | image1
> |
> | owner | 826876d6d3724018bae6253c7f540cb3
> |
> | properties | locations='[]', os_hash_algo='None',
> os_hash_value='None', os_hidden='False' |
> | protected | False
> |
> | schema | /v2/schemas/image
> |
> | size | None
> |
> | status | queued
> |
> | tags |
> |
> | updated_at | 2018-10-18T22:17:41Z
> |
> | virtual_size | None
> |
> | visibility | private
> |
> +------------------+------------------------------------------------------------------------------+
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |
> +--------------------------------------+--------+--------+
> $ export OS_USERNAME=user2
> $ export OS_PROJECT_NAME=project2
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> +--------------------------------------+--------+--------+
> $ export OS_USERNAME=admin
> $ export OS_PROJECT_NAME=admin
> $ export OS_PASSWORD=xxx
> $ openstack image set --public 6a0c1928-b79c-4dbf-a9c9-305b599056e4
> $ export OS_USERNAME=user2
> $ export OS_PROJECT_NAME=project2
> $ export OS_PASSWORD=foo
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |
> +--------------------------------------+--------+--------+
> $
>
>
> On 10/18/2018 03:32 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
> INTEGRA, INC.] wrote:
>> openstack user create --domain default --password xxxxxxxx --project-domain
>> ndc --project test mike
>>
>>
>> openstack role add --user mike --user-domain default --project test user
>>
>> my admin account is in the NDC domain with a different username.
>>
>>
>>
>> /etc/glance/policy.json
>> {
>>
>> "context_is_admin": "role:admin",
>> "default": "role:admin",
>>
>> <snip>
>>
>>
>> I'm not terribly familiar with the policies but I feel like that default
>> line is making everyone an admin by default?
>>
>>
>> Mike Moore, M.S.S.E.
>>
>> Systems Engineer, Goddard Private Cloud
>> Michael.D.Moore at nasa.gov
>>
>> Hydrogen fusion brightens my day.
>>
>>
>> On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>>
>>
>> I suspect that your non-admin user is not really non-admin. How did you
>> create it?
>>
>> What you have for "context_is_admin" in glance's policy.json ?
>>
>> ~iain
>>
>>
>> On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
>> INTEGRA, INC.] wrote:
>>> I have replicated this unexpected behavior in a Pike test environment, in
>>> addition to our Queens environment.
>>>
>>>
>>>
>>> Mike Moore, M.S.S.E.
>>>
>>> Systems Engineer, Goddard Private Cloud
>>> Michael.D.Moore at nasa.gov
>>>
>>> Hydrogen fusion brightens my day.
>>>
>>>
>>> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA,
>>> INC.]" <michael.d.moore at nasa.gov> wrote:
>>>
>>> Yes. I verified it by creating a non-admin user in a different tenant. I
>>> created a new image, set to private with the project defined as our admin
>>> tenant.
>>>
>>> In the database I can see that the image is 'private' and the owner is the
>>> ID of the admin tenant.
>>>
>>> Mike Moore, M.S.S.E.
>>>
>>> Systems Engineer, Goddard Private Cloud
>>> Michael.D.Moore at nasa.gov
>>>
>>> Hydrogen fusion brightens my day.
>>>
>>>
>>> On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>>>
>>>
>>>
>>> On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
>>> INTEGRA, INC.] wrote:
>>> > I’m seeing unexpected behavior in our Queens environment related to
>>> > Glance image visibility. Specifically users who, based on my
>>> > understanding of the visibility and ownership fields, should NOT be able
>>> > to see or view the image.
>>> >
>>> > If I create a new image with openstack image create and specify –project
>>> > <tenant> and –private a non-admin user in a different tenant can see and
>>> > boot that image.
>>> >
>>> > That seems to be the opposite of what should happen. Any ideas?
>>>
>>> Yep, something's not right there.
>>>
>>> Are you sure that the user that can see the image doesn't have the admin
>>> role (for the project in its keystone token) ?
>>>
>>> Did you verify that the image's owner is what you intended, and that the
>>> visibility really is "private" ?
>>>
>>> ~iain
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
------------------------------
Message: 13
Date: Fri, 19 Oct 2018 16:54:12 +0000
From: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"
<michael.d.moore at nasa.gov>
To: Chris Apsey <bitskrieg at bitskrieg.net>, iain MacDonnell
<iain.macdonnell at oracle.com>,
"openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -
Non admin users can see private images from other tenants
Message-ID: <A5FD0CCA-8B13-424D-A8F2-E6ACECF58C23 at nasa.gov>
Content-Type: text/plain; charset="utf-8"
For reference, here is our full glance policy.json
{
"context_is_admin": "role:admin",
"default": "role:admin",
"add_image": "",
"delete_image": "",
"get_image": "",
"get_images": "",
"modify_image": "",
"publicize_image": "role:admin",
"communitize_image": "",
"copy_from": "",
"download_image": "",
"upload_image": "",
"delete_image_location": "",
"get_image_location": "",
"set_image_location": "",
"add_member": "",
"delete_member": "",
"get_member": "",
"get_members": "",
"modify_member": "",
"manage_image_cache": "role:admin",
"get_task": "",
"get_tasks": "",
"add_task": "",
"modify_task": "",
"tasks_api_access": "role:admin",
"deactivate": "",
"reactivate": "",
"get_metadef_namespace": "",
"get_metadef_namespaces":"",
"modify_metadef_namespace":"",
"add_metadef_namespace":"",
"get_metadef_object":"",
"get_metadef_objects":"",
"modify_metadef_object":"",
"add_metadef_object":"",
"list_metadef_resource_types":"",
"get_metadef_resource_type":"",
"add_metadef_resource_type_association":"",
"get_metadef_property":"",
"get_metadef_properties":"",
"modify_metadef_property":"",
"add_metadef_property":"",
"get_metadef_tag":"",
"get_metadef_tags":"",
"modify_metadef_tag":"",
"add_metadef_tag":"",
"add_metadef_tags":""
}
Mike Moore, M.S.S.E.
Systems Engineer, Goddard Private Cloud
Michael.D.Moore at nasa.gov
Hydrogen fusion brightens my day.
On 10/19/18, 12:39 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore at nasa.gov> wrote:
Our NDC domain is LDAP backed. Default is not.
Our keystone policy.json file is empty {}
Mike Moore, M.S.S.E.
Systems Engineer, Goddard Private Cloud
Michael.D.Moore at nasa.gov
Hydrogen fusion brightens my day.
On 10/18/18, 7:24 PM, "Chris Apsey" <bitskrieg at bitskrieg.net> wrote:
We are using multiple keystone domains - still can't reproduce this.
Do you happen to have a customized keystone policy.json?
Worst case, I would launch a devstack of your targeted release. If you
can't reproduce the issue there, you would at least know its caused by a
nonstandard config rather than a bug (or at least not a bug that's present
when using a default config)
On October 18, 2018 18:50:12 iain MacDonnell <iain.macdonnell at oracle.com>
wrote:
> That all looks fine.
>
> I believe that the "default" policy applies in place of any that's not
> explicitly specified - i.e. "if there's no matching policy below, you
> need to have the admin role to be able to do it". I do have that line in
> my policy.json, and I cannot reproduce your problem (see below).
>
> I'm not using domains (other than "default"). I wonder if that's a factor...
>
> ~iain
>
>
> $ openstack user create --password foo user1
> +---------------------+----------------------------------+
> | Field | Value |
> +---------------------+----------------------------------+
> | domain_id | default |
> | enabled | True |
> | id | d18c0031ec56430499a2d690cb1f125c |
> | name | user1 |
> | options | {} |
> | password_expires_at | None |
> +---------------------+----------------------------------+
> $ openstack user create --password foo user2
> +---------------------+----------------------------------+
> | Field | Value |
> +---------------------+----------------------------------+
> | domain_id | default |
> | enabled | True |
> | id | be9f1061a5104abd834eabe98dff055d |
> | name | user2 |
> | options | {} |
> | password_expires_at | None |
> +---------------------+----------------------------------+
> $ openstack project create project1
> +-------------+----------------------------------+
> | Field | Value |
> +-------------+----------------------------------+
> | description | |
> | domain_id | default |
> | enabled | True |
> | id | 826876d6d3724018bae6253c7f540cb3 |
> | is_domain | False |
> | name | project1 |
> | parent_id | default |
> | tags | [] |
> +-------------+----------------------------------+
> $ openstack project create project2
> +-------------+----------------------------------+
> | Field | Value |
> +-------------+----------------------------------+
> | description | |
> | domain_id | default |
> | enabled | True |
> | id | b446b93ac6e24d538c1943acbdd13cb2 |
> | is_domain | False |
> | name | project2 |
> | parent_id | default |
> | tags | [] |
> +-------------+----------------------------------+
> $ openstack role add --user user1 --project project1 _member_
> $ openstack role add --user user2 --project project2 _member_
> $ export OS_PASSWORD=foo
> $ export OS_USERNAME=user1
> $ export OS_PROJECT_NAME=project1
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> +--------------------------------------+--------+--------+
> $ openstack image create --private image1
> +------------------+------------------------------------------------------------------------------+
> | Field | Value
> |
> +------------------+------------------------------------------------------------------------------+
> | checksum | None
> |
> | container_format | bare
> |
> | created_at | 2018-10-18T22:17:41Z
> |
> | disk_format | raw
> |
> | file |
> /v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file
> |
> | id | 6a0c1928-b79c-4dbf-a9c9-305b599056e4
> |
> | min_disk | 0
> |
> | min_ram | 0
> |
> | name | image1
> |
> | owner | 826876d6d3724018bae6253c7f540cb3
> |
> | properties | locations='[]', os_hash_algo='None',
> os_hash_value='None', os_hidden='False' |
> | protected | False
> |
> | schema | /v2/schemas/image
> |
> | size | None
> |
> | status | queued
> |
> | tags |
> |
> | updated_at | 2018-10-18T22:17:41Z
> |
> | virtual_size | None
> |
> | visibility | private
> |
> +------------------+------------------------------------------------------------------------------+
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |
> +--------------------------------------+--------+--------+
> $ export OS_USERNAME=user2
> $ export OS_PROJECT_NAME=project2
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> +--------------------------------------+--------+--------+
> $ export OS_USERNAME=admin
> $ export OS_PROJECT_NAME=admin
> $ export OS_PASSWORD=xxx
> $ openstack image set --public 6a0c1928-b79c-4dbf-a9c9-305b599056e4
> $ export OS_USERNAME=user2
> $ export OS_PROJECT_NAME=project2
> $ export OS_PASSWORD=foo
> $ openstack image list
> +--------------------------------------+--------+--------+
> | ID | Name | Status |
> +--------------------------------------+--------+--------+
> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
> | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |
> +--------------------------------------+--------+--------+
> $
>
>
> On 10/18/2018 03:32 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
> INTEGRA, INC.] wrote:
>> openstack user create --domain default --password xxxxxxxx --project-domain
>> ndc --project test mike
>>
>>
>> openstack role add --user mike --user-domain default --project test user
>>
>> my admin account is in the NDC domain with a different username.
>>
>>
>>
>> /etc/glance/policy.json
>> {
>>
>> "context_is_admin": "role:admin",
>> "default": "role:admin",
>>
>> <snip>
>>
>>
>> I'm not terribly familiar with the policies but I feel like that default
>> line is making everyone an admin by default?
>>
>>
>> Mike Moore, M.S.S.E.
>>
>> Systems Engineer, Goddard Private Cloud
>> Michael.D.Moore at nasa.gov
>>
>> Hydrogen fusion brightens my day.
>>
>>
>> On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>>
>>
>> I suspect that your non-admin user is not really non-admin. How did you
>> create it?
>>
>> What you have for "context_is_admin" in glance's policy.json ?
>>
>> ~iain
>>
>>
>> On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
>> INTEGRA, INC.] wrote:
>>> I have replicated this unexpected behavior in a Pike test environment, in
>>> addition to our Queens environment.
>>>
>>>
>>>
>>> Mike Moore, M.S.S.E.
>>>
>>> Systems Engineer, Goddard Private Cloud
>>> Michael.D.Moore at nasa.gov
>>>
>>> Hydrogen fusion brightens my day.
>>>
>>>
>>> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA,
>>> INC.]" <michael.d.moore at nasa.gov> wrote:
>>>
>>> Yes. I verified it by creating a non-admin user in a different tenant. I
>>> created a new image, set to private with the project defined as our admin
>>> tenant.
>>>
>>> In the database I can see that the image is 'private' and the owner is the
>>> ID of the admin tenant.
>>>
>>> Mike Moore, M.S.S.E.
>>>
>>> Systems Engineer, Goddard Private Cloud
>>> Michael.D.Moore at nasa.gov
>>>
>>> Hydrogen fusion brightens my day.
>>>
>>>
>>> On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell at oracle.com> wrote:
>>>
>>>
>>>
>>> On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
>>> INTEGRA, INC.] wrote:
>>> > I’m seeing unexpected behavior in our Queens environment related to
>>> > Glance image visibility. Specifically users who, based on my
>>> > understanding of the visibility and ownership fields, should NOT be able
>>> > to see or view the image.
>>> >
>>> > If I create a new image with openstack image create and specify –project
>>> > <tenant> and –private a non-admin user in a different tenant can see and
>>> > boot that image.
>>> >
>>> > That seems to be the opposite of what should happen. Any ideas?
>>>
>>> Yep, something's not right there.
>>>
>>> Are you sure that the user that can see the image doesn't have the admin
>>> role (for the project in its keystone token) ?
>>>
>>> Did you verify that the image's owner is what you intended, and that the
>>> visibility really is "private" ?
>>>
>>> ~iain
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e=
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
------------------------------
Message: 14
Date: Fri, 19 Oct 2018 13:45:03 -0400
From: Jay Pipes <jaypipes at gmail.com>
To: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] Fleio - OpenStack billing - ver.
1.1 released
Message-ID: <b3f680a3-71ef-5c55-6dea-d71c9d973640 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Please do not use these mailing lists to advertise
closed-source/proprietary software solutions.
Thank you,
-jay
On 10/19/2018 05:42 AM, Adrian Andreias wrote:
> Hello,
>
> We've just released Fleio version 1.1.
>
> Fleio is a billing solution and control panel for OpenStack public
> clouds and traditional web hosters.
>
> Fleio software automates the entire process for cloud users. New
> customers can use Fleio to sign up for an account, pay invoices, add
> credit to their account, as well as create and manage cloud resources
> such as virtual machines, storage and networking.
>
> Full feature list:
> https://fleio.com#features
>
> You can see an online demo:
> https://fleio.com/demo
>
> And sign-up for a free trial:
> https://fleio.com/signup
>
>
>
> Cheers!
>
> - Adrian Andreias
> https://fleio.com
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
------------------------------
Message: 15
Date: Fri, 19 Oct 2018 20:13:40 +0200
From: Mohammed Naser <mnaser at vexxhost.com>
To: jaypipes at gmail.com
Cc: openstack-operators <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Fleio - OpenStack billing - ver.
1.1 released
Message-ID:
<CAEs876gDHPFjgxnD+HHKyP782u2XX0attJq9dYiYFDibc6DTZQ at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Fri, Oct 19, 2018 at 7:45 PM Jay Pipes <jaypipes at gmail.com> wrote:
>
> Please do not use these mailing lists to advertise
> closed-source/proprietary software solutions.
+1
> Thank you,
> -jay
>
> On 10/19/2018 05:42 AM, Adrian Andreias wrote:
> > Hello,
> >
> > We've just released Fleio version 1.1.
> >
> > Fleio is a billing solution and control panel for OpenStack public
> > clouds and traditional web hosters.
> >
> > Fleio software automates the entire process for cloud users. New
> > customers can use Fleio to sign up for an account, pay invoices, add
> > credit to their account, as well as create and manage cloud resources
> > such as virtual machines, storage and networking.
> >
> > Full feature list:
> > https://fleio.com#features
> >
> > You can see an online demo:
> > https://fleio.com/demo
> >
> > And sign-up for a free trial:
> > https://fleio.com/signup
> >
> >
> >
> > Cheers!
> >
> > - Adrian Andreias
> > https://fleio.com
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com
------------------------------
Message: 16
Date: Fri, 19 Oct 2018 14:39:29 -0400
From: Erik McCormick <emccormick at cirrusseven.com>
To: openstack-operators <openstack-operators at lists.openstack.org>
Subject: [Openstack-operators] [Octavia] SSL errors polling amphorae
and missing tenant network interface
Message-ID:
<CAHUi5cNByYFRr4vHY9iAEhAFc=MhdjhBWHNArCQG0D-w-Z2gFg at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
I've been wrestling with getting Octavia up and running and have
become stuck on two issues. I'm hoping someone has run into these
before. My google foo has come up empty.
Issue 1:
When the Octavia controller tries to poll the amphora instance, it
tries repeatedly and eventually fails. The error on the controller
side is:
2018-10-19 14:17:39.181 26 ERROR
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Connection
retries (currently set to 300) exhausted. The amphora is unavailable.
Reason: HTTPSConnectionPool(host='10.7.0.112', port=9443): Max retries
exceeded with url: /0.5/plug/vip/10.250.20.15 (Caused by
SSLError(SSLError("bad handshake: Error([('rsa routines',
'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',
'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding
routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',
'tls_process_server_certificate', 'certificate verify
failed')],)",),)): SSLError: HTTPSConnectionPool(host='10.7.0.112',
port=9443): Max retries exceeded with url: /0.5/plug/vip/10.250.20.15
(Caused by SSLError(SSLError("bad handshake: Error([('rsa routines',
'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',
'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding
routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',
'tls_process_server_certificate', 'certificate verify
failed')],)",),))
On the amphora side I see:
[2018-10-19 17:52:54 +0000] [1331] [DEBUG] Error processing SSL request.
[2018-10-19 17:52:54 +0000] [1331] [DEBUG] Invalid request from
ip=::ffff:10.7.0.40: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake
failure (_ssl.c:1754)
I've generated certificates both with the script in the Octavia git
repo, and with the Openstack Ansible playbook. I can see that they are
present in /etc/octavia/certs.
I'm using the Kolla (Queens) containers for the control plane so I'm
sure I've satisfied all the python library constraints.
Issue 2:
I"m not sure how it gets configured, but the tenant network interface
(ens6) never comes up. I can spawn other instances on that network
with no issue, and I can see that Neutron has the port attached to the
instance. However, in the instance this is all I get:
ubuntu at amphora-33e0aab3-8bc4-4fcb-bc42-b9b36afb16d4:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast
state UP group default qlen 1000
link/ether fa:16:3e:30:c4:60 brd ff:ff:ff:ff:ff:ff
inet 10.7.0.112/16 brd 10.7.255.255 scope global ens3
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe30:c460/64 scope link
valid_lft forever preferred_lft forever
3: ens6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether fa:16:3e:89:a2:7f brd ff:ff:ff:ff:ff:ff
There's no evidence of the interface anywhere else including udev rules.
Any help with either or both issues would be greatly appreciated.
Cheers,
Erik
------------------------------
Message: 17
Date: Sat, 20 Oct 2018 01:47:42 +0200
From: Gaël THEROND <gael.therond at gmail.com>
To: Erik McCormick <emccormick at cirrusseven.com>
Cc: openstack-operators <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] [Octavia] SSL errors polling
amphorae and missing tenant network interface
Message-ID:
<CAG+53ua-Hcjjq=_00rUZNsATmWq7g_8uZbMXAB_9VghtR_ByZA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi eric!
Glad I’m not the only one having this issue with the ssl communication
between the amphora and the CP.
Even if I don’t yet get a clear answer regarding that issue, I think your
second issue is not an issue as the interface is mounted on a namespace and
so you’ll need to list all nic even those from namespace.
Use an ip netns ls to get the namespace.
Hope it will help.
Le ven. 19 oct. 2018 à 20:40, Erik McCormick <emccormick at cirrusseven.com> a
écrit :
> I've been wrestling with getting Octavia up and running and have
> become stuck on two issues. I'm hoping someone has run into these
> before. My google foo has come up empty.
>
> Issue 1:
> When the Octavia controller tries to poll the amphora instance, it
> tries repeatedly and eventually fails. The error on the controller
> side is:
>
> 2018-10-19 14:17:39.181 26 ERROR
> octavia.amphorae.drivers.haproxy.rest_api_driver [-] Connection
> retries (currently set to 300) exhausted. The amphora is unavailable.
> Reason: HTTPSConnectionPool(host='10.7.0.112', port=9443): Max retries
> exceeded with url: /0.5/plug/vip/10.250.20.15 (Caused by
> SSLError(SSLError("bad handshake: Error([('rsa routines',
> 'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',
> 'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding
> routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',
> 'tls_process_server_certificate', 'certificate verify
> failed')],)",),)): SSLError: HTTPSConnectionPool(host='10.7.0.112',
> port=9443): Max retries exceeded with url: /0.5/plug/vip/10.250.20.15
> (Caused by SSLError(SSLError("bad handshake: Error([('rsa routines',
> 'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',
> 'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding
> routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',
> 'tls_process_server_certificate', 'certificate verify
> failed')],)",),))
>
> On the amphora side I see:
> [2018-10-19 17:52:54 +0000] [1331] [DEBUG] Error processing SSL request.
> [2018-10-19 17:52:54 +0000] [1331] [DEBUG] Invalid request from
> ip=::ffff:10.7.0.40: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake
> failure (_ssl.c:1754)
>
> I've generated certificates both with the script in the Octavia git
> repo, and with the Openstack Ansible playbook. I can see that they are
> present in /etc/octavia/certs.
>
> I'm using the Kolla (Queens) containers for the control plane so I'm
> sure I've satisfied all the python library constraints.
>
> Issue 2:
> I"m not sure how it gets configured, but the tenant network interface
> (ens6) never comes up. I can spawn other instances on that network
> with no issue, and I can see that Neutron has the port attached to the
> instance. However, in the instance this is all I get:
>
> ubuntu at amphora-33e0aab3-8bc4-4fcb-bc42-b9b36afb16d4:~$ ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast
> state UP group default qlen 1000
> link/ether fa:16:3e:30:c4:60 brd ff:ff:ff:ff:ff:ff
> inet 10.7.0.112/16 brd 10.7.255.255 scope global ens3
> valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fe30:c460/64 scope link
> valid_lft forever preferred_lft forever
> 3: ens6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether fa:16:3e:89:a2:7f brd ff:ff:ff:ff:ff:ff
>
> There's no evidence of the interface anywhere else including udev rules.
>
> Any help with either or both issues would be greatly appreciated.
>
> Cheers,
> Erik
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20181020/71c8e27a/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
------------------------------
End of OpenStack-operators Digest, Vol 96, Issue 7
**************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20181020/8c228be0/attachment-0001.html>
More information about the OpenStack-operators
mailing list