<html dir="ltr">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<style type="text/css" id="owaParaStyle"></style>

</head>

<body fpstyle="1" ocsi="0">

<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">

<div><br>

</div>

<div><br>

</div>

<div><br>

</div>

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.

<div><br>

</div>

<div><br>

<div style="font-family: Times New Roman; color: #000000; font-size: 16px">

<hr tabindex="-1">

<div id="divRpF724509" style="direction: ltr;"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Logan Hicks [logan.hicks@live.com]<br>

<b>Sent:</b> Friday, October 19, 2018 8:00 PM<br>

<b>To:</b> openstack-operators@lists.openstack.org<br>

<b>Subject:</b> Re: [Openstack-operators] OpenStack-operators Digest, Vol 96, Issue 7<br>

</font><br>

</div>

<div></div>

<div>

<div>Re: Glance Image Visibility Issue? - Non  admin users can see<br>

      private images from other tenants (Chris Apsey)</div>

<div><br>

</div>

<div>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.</div>

<div><br>

</div>

<div>The object doesnt exist until its made by openstack.</div>

<div><br>

</div>

<div>Id check to see if something is holding up images being made. Id start with glance.</div>

<div><br>

</div>

<div><br>

</div>

<div><br>

</div>

<div id="composer_signature">Respectfully,

<div><br>

</div>

<div>Logan Hicks</div>

</div>

<div><br>

</div>

<div style="font-size:100%; color:#000000">

<div>-------- Original message --------</div>

<div>From: openstack-operators-request@lists.openstack.org </div>

<div>Date: 10/19/18 7:49 PM (GMT-05:00) </div>

<div>To: openstack-operators@lists.openstack.org </div>

<div>Subject: OpenStack-operators Digest, Vol 96, Issue 7 </div>

<div><br>

</div>

</div>

<font size="2"><span style="font-size:11pt">

<div class="PlainText">Send OpenStack-operators mailing list submissions to<br>

        openstack-operators@lists.openstack.org<br>

<br>

To subscribe or unsubscribe via the World Wide Web, visit<br>

        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

<br>

or, via email, send a message with subject or body 'help' to<br>

        openstack-operators-request@lists.openstack.org<br>

<br>

You can reach the person managing the list at<br>

        openstack-operators-owner@lists.openstack.org<br>

<br>

When replying, please edit your Subject line so it is more specific<br>

than "Re: Contents of OpenStack-operators digest..."<br>

<br>

<br>

Today's Topics:<br>

<br>

   1. [nova] Removing the CachingScheduler (Matt Riedemann)<br>

   2. Re: Glance Image Visibility Issue? - Non admin users can see<br>

      private images from other tenants<br>

      (Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.])<br>

   3. Re: Glance Image Visibility Issue? - Non  admin users can see<br>

      private images from other tenants (Chris Apsey)<br>

   4. Re: Glance Image Visibility Issue? - Non admin users can see<br>

      private images from other tenants (iain MacDonnell)<br>

   5. Re: Glance Image Visibility Issue? - Non admin users can see<br>

      private images from other tenants<br>

      (Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.])<br>

   6. Re: Glance Image Visibility Issue? - Non admin users can see<br>

      private images from other tenants (iain MacDonnell)<br>

   7. Re: Glance Image Visibility Issue? - Non  admin users can see<br>

      private images from other tenants (Chris Apsey)<br>

   8. osops-tools-monitoring Dependency problems (Tomáš Vondra)<br>

   9. [heat][cinder] How to create stack snapshot       including volumes<br>

      (Christian Zunker)<br>

  10. Fleio - OpenStack billing - ver. 1.1 released (Adrian Andreias)<br>

  11. Re: [Openstack-sigs] [all] Naming the T   release of OpenStack<br>

      (Tony Breeds)<br>

  12. Re: Glance Image Visibility Issue? - Non admin users can see<br>

      private images from other tenants<br>

      (Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.])<br>

  13. Re: Glance Image Visibility Issue? - Non admin users can see<br>

      private images from other tenants<br>

      (Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.])<br>

  14. Re: Fleio - OpenStack billing - ver. 1.1 released (Jay Pipes)<br>

  15. Re: Fleio - OpenStack billing - ver. 1.1  released (Mohammed Naser)<br>

  16. [Octavia] SSL errors polling amphorae and missing tenant<br>

      network interface (Erik McCormick)<br>

  17. Re: [Octavia] SSL errors polling amphorae and missing tenant<br>

      network interface (Gaël THEROND)<br>

<br>

<br>

----------------------------------------------------------------------<br>

<br>

Message: 1<br>

Date: Thu, 18 Oct 2018 17:07:00 -0500<br>

From: Matt Riedemann <mriedemos@gmail.com><br>

To: "openstack-operators@lists.openstack.org"<br>

        <openstack-operators@lists.openstack.org><br>

Subject: [Openstack-operators] [nova] Removing the CachingScheduler<br>

Message-ID: <fa0c5339-a54d-6720-ca10-7f0cff12dba1@gmail.com><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

It's been deprecated since Pike, and the time has come to remove it [1].<br>

<br>

mgagne has been the most vocal CachingScheduler operator I know and he <br>

has tested out the "nova-manage placement heal_allocations" CLI, added <br>

in Rocky, and said it will work for migrating his deployment from the <br>

CachingScheduler to the FilterScheduler + Placement.<br>

<br>

If you are using the CachingScheduler and have a problem with its <br>

removal, now is the time to speak up or forever hold your peace.<br>

<br>

[1] <a href="https://review.openstack.org/#/c/611723/1" target="_blank">https://review.openstack.org/#/c/611723/1</a><br>

<br>

-- <br>

<br>

Thanks,<br>

<br>

Matt<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 2<br>

Date: Thu, 18 Oct 2018 22:11:40 +0000<br>

From: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"<br>

        <michael.d.moore@nasa.gov><br>

To: iain MacDonnell <iain.macdonnell@oracle.com>,<br>

        "openstack-operators@lists.openstack.org"<br>

        <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -<br>

        Non admin users can see private images from other tenants<br>

Message-ID: <EDBAEC2C-5245-4952-86C9-CDC635667C92@nasa.gov><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

I have replicated this unexpected behavior in a Pike test environment, in addition to our Queens environment.<br>

<br>

<br>

<br>

Mike Moore, M.S.S.E.<br>

 <br>

Systems Engineer, Goddard Private Cloud<br>

Michael.D.Moore@nasa.gov<br>

 <br>

Hydrogen fusion brightens my day.<br>

 <br>

<br>

On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore@nasa.gov> wrote:<br>

<br>

    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.<br>

    <br>

    In the database I can see that the image is 'private' and the owner is the ID of the admin tenant.<br>

    <br>

    Mike Moore, M.S.S.E.<br>

     <br>

    Systems Engineer, Goddard Private Cloud<br>

    Michael.D.Moore@nasa.gov<br>

     <br>

    Hydrogen fusion brightens my day.<br>

     <br>

    <br>

    On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

    <br>

        <br>

        <br>

        On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS <br>

        INTEGRA, INC.] wrote:<br>

        > I’m seeing unexpected behavior in our Queens environment related to <br>

        > Glance image visibility. Specifically users who, based on my <br>

        > understanding of the visibility and ownership fields, should NOT be able

<br>

        > to see or view the image.<br>

        > <br>

        > If I create a new image with openstack image create and specify –project

<br>

        > <tenant> and –private a non-admin user in a different tenant can see and

<br>

        > boot that image.<br>

        > <br>

        > That seems to be the opposite of what should happen. Any ideas?<br>

        <br>

        Yep, something's not right there.<br>

        <br>

        Are you sure that the user that can see the image doesn't have the admin <br>

        role (for the project in its keystone token) ?<br>

        <br>

        Did you verify that the image's owner is what you intended, and that the <br>

        visibility really is "private" ?<br>

        <br>

             ~iain<br>

        <br>

        _______________________________________________<br>

        OpenStack-operators mailing list<br>

        OpenStack-operators@lists.openstack.org<br>

        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

        <br>

    <br>

    _______________________________________________<br>

    OpenStack-operators mailing list<br>

    OpenStack-operators@lists.openstack.org<br>

    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

    <br>

<br>

<br>

------------------------------<br>

<br>

Message: 3<br>

Date: Thu, 18 Oct 2018 18:23:35 -0400<br>

From: Chris Apsey <bitskrieg@bitskrieg.net><br>

To: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"<br>

        <michael.d.moore@nasa.gov>, iain MacDonnell<br>

        <iain.macdonnell@oracle.com>,<br>

        <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -<br>

        Non     admin users can see private images from other tenants<br>

Message-ID:<br>

        <1668946da70.278c.5f0d7f2baa7831a2bbe6450f254d9a24@bitskrieg.net><br>

Content-Type: text/plain; format=flowed; charset="UTF-8"<br>

<br>

Do you have a liberal/custom policy.json that perhaps is causing unexpected <br>

behavior?  Can't seem to reproduce this.<br>

<br>

On October 18, 2018 18:13:22 "Moore, Michael Dane (GSFC-720.0)[BUSINESS <br>

INTEGRA, INC.]" <michael.d.moore@nasa.gov> wrote:<br>

<br>

> I have replicated this unexpected behavior in a Pike test environment, in <br>

> addition to our Queens environment.<br>

><br>

><br>

><br>

> Mike Moore, M.S.S.E.<br>

><br>

> Systems Engineer, Goddard Private Cloud<br>

> Michael.D.Moore@nasa.gov<br>

><br>

> Hydrogen fusion brightens my day.<br>

><br>

><br>

> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, <br>

> INC.]" <michael.d.moore@nasa.gov> wrote:<br>

><br>

>    Yes. I verified it by creating a non-admin user in a different tenant. I <br>

>    created a new image, set to private with the project defined as our admin <br>

>    tenant.<br>

><br>

>    In the database I can see that the image is 'private' and the owner is the <br>

>    ID of the admin tenant.<br>

><br>

>    Mike Moore, M.S.S.E.<br>

><br>

>    Systems Engineer, Goddard Private Cloud<br>

>    Michael.D.Moore@nasa.gov<br>

><br>

>    Hydrogen fusion brightens my day.<br>

><br>

><br>

>    On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

><br>

><br>

><br>

>        On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

>        INTEGRA, INC.] wrote:<br>

>> I’m seeing unexpected behavior in our Queens environment related to<br>

>> Glance image visibility. Specifically users who, based on my<br>

>> understanding of the visibility and ownership fields, should NOT be able<br>

>> to see or view the image.<br>

>><br>

>> If I create a new image with openstack image create and specify –project<br>

>> <tenant> and –private a non-admin user in a different tenant can see and<br>

>> boot that image.<br>

>><br>

>> That seems to be the opposite of what should happen. Any ideas?<br>

><br>

>        Yep, something's not right there.<br>

><br>

>        Are you sure that the user that can see the image doesn't have the admin<br>

>        role (for the project in its keystone token) ?<br>

><br>

>        Did you verify that the image's owner is what you intended, and that the<br>

>        visibility really is "private" ?<br>

><br>

>             ~iain<br>

><br>

>        _______________________________________________<br>

>        OpenStack-operators mailing list<br>

>        OpenStack-operators@lists.openstack.org<br>

>        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

><br>

><br>

>    _______________________________________________<br>

>    OpenStack-operators mailing list<br>

>    OpenStack-operators@lists.openstack.org<br>

>    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

><br>

><br>

> _______________________________________________<br>

> OpenStack-operators mailing list<br>

> OpenStack-operators@lists.openstack.org<br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

<br>

<br>

<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 4<br>

Date: Thu, 18 Oct 2018 15:25:22 -0700<br>

From: iain MacDonnell <iain.macdonnell@oracle.com><br>

To: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"<br>

        <michael.d.moore@nasa.gov>, "openstack-operators@lists.openstack.org"<br>

        <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -<br>

        Non admin users can see private images from other tenants<br>

Message-ID: <11e3f7a6-875e-4b6c-259a-147188a860e1@oracle.com><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

<br>

I suspect that your non-admin user is not really non-admin. How did you <br>

create it?<br>

<br>

What you have for "context_is_admin" in glance's policy.json ?<br>

<br>

     ~iain<br>

<br>

<br>

On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS <br>

INTEGRA, INC.] wrote:<br>

> I have replicated this unexpected behavior in a Pike test environment, in addition to our Queens environment.<br>

> <br>

> <br>

> <br>

> Mike Moore, M.S.S.E.<br>

>   <br>

> Systems Engineer, Goddard Private Cloud<br>

> Michael.D.Moore@nasa.gov<br>

>   <br>

> Hydrogen fusion brightens my day.<br>

>   <br>

> <br>

> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore@nasa.gov> wrote:<br>

> <br>

>      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.<br>

>      <br>

>      In the database I can see that the image is 'private' and the owner is the ID of the admin tenant.<br>

>      <br>

>      Mike Moore, M.S.S.E.<br>

>       <br>

>      Systems Engineer, Goddard Private Cloud<br>

>      Michael.D.Moore@nasa.gov<br>

>       <br>

>      Hydrogen fusion brightens my day.<br>

>       <br>

>      <br>

>      On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

>      <br>

>          <br>

>          <br>

>          On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

>          INTEGRA, INC.] wrote:<br>

>          > I’m seeing unexpected behavior in our Queens environment related to<br>

>          > Glance image visibility. Specifically users who, based on my<br>

>          > understanding of the visibility and ownership fields, should NOT be able<br>

>          > to see or view the image.<br>

>          ><br>

>          > If I create a new image with openstack image create and specify –project<br>

>          > <tenant> and –private a non-admin user in a different tenant can see and<br>

>          > boot that image.<br>

>          ><br>

>          > That seems to be the opposite of what should happen. Any ideas?<br>

>          <br>

>          Yep, something's not right there.<br>

>          <br>

>          Are you sure that the user that can see the image doesn't have the admin<br>

>          role (for the project in its keystone token) ?<br>

>          <br>

>          Did you verify that the image's owner is what you intended, and that the<br>

>          visibility really is "private" ?<br>

>          <br>

>               ~iain<br>

>          <br>

>          _______________________________________________<br>

>          OpenStack-operators mailing list<br>

>          OpenStack-operators@lists.openstack.org<br>

>          <a href="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=" target="_blank">

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=</a><br>

>          <br>

>      <br>

>      _______________________________________________<br>

>      OpenStack-operators mailing list<br>

>      OpenStack-operators@lists.openstack.org<br>

>      <a href="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=" target="_blank">

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=</a><br>

>      <br>

> <br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 5<br>

Date: Thu, 18 Oct 2018 22:32:42 +0000<br>

From: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"<br>

        <michael.d.moore@nasa.gov><br>

To: iain MacDonnell <iain.macdonnell@oracle.com>,<br>

        "openstack-operators@lists.openstack.org"<br>

        <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -<br>

        Non admin users can see private images from other tenants<br>

Message-ID: <44085CC4-899C-49B2-9934-0800F6650B0B@nasa.gov><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

openstack user create --domain default --password xxxxxxxx --project-domain ndc --project test mike<br>

<br>

<br>

openstack role add --user mike --user-domain default --project test user<br>

<br>

my admin account is in the NDC domain with a different username.<br>

<br>

<br>

<br>

/etc/glance/policy.json <br>

{<br>

<br>

"context_is_admin":  "role:admin",<br>

"default": "role:admin",<br>

<br>

<snip><br>

<br>

<br>

I'm not terribly familiar with the policies but I feel like that default line is making everyone an admin by default?<br>

<br>

<br>

Mike Moore, M.S.S.E.<br>

 <br>

Systems Engineer, Goddard Private Cloud<br>

Michael.D.Moore@nasa.gov<br>

 <br>

Hydrogen fusion brightens my day.<br>

 <br>

<br>

On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

<br>

    <br>

    I suspect that your non-admin user is not really non-admin. How did you <br>

    create it?<br>

    <br>

    What you have for "context_is_admin" in glance's policy.json ?<br>

    <br>

         ~iain<br>

    <br>

    <br>

    On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS <br>

    INTEGRA, INC.] wrote:<br>

    > I have replicated this unexpected behavior in a Pike test environment, in addition to our Queens environment.<br>

    > <br>

    > <br>

    > <br>

    > Mike Moore, M.S.S.E.<br>

    >   <br>

    > Systems Engineer, Goddard Private Cloud<br>

    > Michael.D.Moore@nasa.gov<br>

    >   <br>

    > Hydrogen fusion brightens my day.<br>

    >   <br>

    > <br>

    > On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore@nasa.gov> wrote:<br>

    > <br>

    >      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.<br>

    >      <br>

    >      In the database I can see that the image is 'private' and the owner is the ID of the admin tenant.<br>

    >      <br>

    >      Mike Moore, M.S.S.E.<br>

    >       <br>

    >      Systems Engineer, Goddard Private Cloud<br>

    >      Michael.D.Moore@nasa.gov<br>

    >       <br>

    >      Hydrogen fusion brightens my day.<br>

    >       <br>

    >      <br>

    >      On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

    >      <br>

    >          <br>

    >          <br>

    >          On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

    >          INTEGRA, INC.] wrote:<br>

    >          > I’m seeing unexpected behavior in our Queens environment related to<br>

    >          > Glance image visibility. Specifically users who, based on my<br>

    >          > understanding of the visibility and ownership fields, should NOT be able<br>

    >          > to see or view the image.<br>

    >          ><br>

    >          > If I create a new image with openstack image create and specify –project<br>

    >          > <tenant> and –private a non-admin user in a different tenant can see and<br>

    >          > boot that image.<br>

    >          ><br>

    >          > That seems to be the opposite of what should happen. Any ideas?<br>

    >          <br>

    >          Yep, something's not right there.<br>

    >          <br>

    >          Are you sure that the user that can see the image doesn't have the admin<br>

    >          role (for the project in its keystone token) ?<br>

    >          <br>

    >          Did you verify that the image's owner is what you intended, and that the<br>

    >          visibility really is "private" ?<br>

    >          <br>

    >               ~iain<br>

    >          <br>

    >          _______________________________________________<br>

    >          OpenStack-operators mailing list<br>

    >          OpenStack-operators@lists.openstack.org<br>

    >          <a href="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=" target="_blank">

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=</a><br>

    >          <br>

    >      <br>

    >      _______________________________________________<br>

    >      OpenStack-operators mailing list<br>

    >      OpenStack-operators@lists.openstack.org<br>

    >      <a href="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=" target="_blank">

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=</a><br>

    >      <br>

    > <br>

    <br>

<br>

<br>

------------------------------<br>

<br>

Message: 6<br>

Date: Thu, 18 Oct 2018 15:48:27 -0700<br>

From: iain MacDonnell <iain.macdonnell@oracle.com><br>

To: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"<br>

        <michael.d.moore@nasa.gov>, "openstack-operators@lists.openstack.org"<br>

        <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -<br>

        Non admin users can see private images from other tenants<br>

Message-ID: <c8bb19c1-8dcb-7f68-db3e-199cefd5c442@oracle.com><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

<br>

That all looks fine.<br>

<br>

I believe that the "default" policy applies in place of any that's not <br>

explicitly specified - i.e. "if there's no matching policy below, you <br>

need to have the admin role to be able to do it". I do have that line in <br>

my policy.json, and I cannot reproduce your problem (see below).<br>

<br>

I'm not using domains (other than "default"). I wonder if that's a factor...<br>

<br>

     ~iain<br>

<br>

<br>

$ openstack user create --password foo user1<br>

+---------------------+----------------------------------+<br>

| Field               | Value                            |<br>

+---------------------+----------------------------------+<br>

| domain_id           | default                          |<br>

| enabled             | True                             |<br>

| id                  | d18c0031ec56430499a2d690cb1f125c |<br>

| name                | user1                            |<br>

| options             | {}                               |<br>

| password_expires_at | None                             |<br>

+---------------------+----------------------------------+<br>

$ openstack user create --password foo user2<br>

+---------------------+----------------------------------+<br>

| Field               | Value                            |<br>

+---------------------+----------------------------------+<br>

| domain_id           | default                          |<br>

| enabled             | True                             |<br>

| id                  | be9f1061a5104abd834eabe98dff055d |<br>

| name                | user2                            |<br>

| options             | {}                               |<br>

| password_expires_at | None                             |<br>

+---------------------+----------------------------------+<br>

$ openstack project create project1<br>

+-------------+----------------------------------+<br>

| Field       | Value                            |<br>

+-------------+----------------------------------+<br>

| description |                                  |<br>

| domain_id   | default                          |<br>

| enabled     | True                             |<br>

| id          | 826876d6d3724018bae6253c7f540cb3 |<br>

| is_domain   | False                            |<br>

| name        | project1                         |<br>

| parent_id   | default                          |<br>

| tags        | []                               |<br>

+-------------+----------------------------------+<br>

$ openstack project create project2<br>

+-------------+----------------------------------+<br>

| Field       | Value                            |<br>

+-------------+----------------------------------+<br>

| description |                                  |<br>

| domain_id   | default                          |<br>

| enabled     | True                             |<br>

| id          | b446b93ac6e24d538c1943acbdd13cb2 |<br>

| is_domain   | False                            |<br>

| name        | project2                         |<br>

| parent_id   | default                          |<br>

| tags        | []                               |<br>

+-------------+----------------------------------+<br>

$ openstack role add --user user1 --project project1 _member_<br>

$ openstack role add --user user2 --project project2 _member_<br>

$ export OS_PASSWORD=foo<br>

$ export OS_USERNAME=user1<br>

$ export OS_PROJECT_NAME=project1<br>

$ openstack image list<br>

+--------------------------------------+--------+--------+<br>

| ID                                   | Name   | Status |<br>

+--------------------------------------+--------+--------+<br>

| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

+--------------------------------------+--------+--------+<br>

$ openstack image create --private image1<br>

+------------------+------------------------------------------------------------------------------+<br>

| Field            | Value <br>

                          |<br>

+------------------+------------------------------------------------------------------------------+<br>

| checksum         | None <br>

                          |<br>

| container_format | bare <br>

                          |<br>

| created_at       | 2018-10-18T22:17:41Z <br>

                          |<br>

| disk_format      | raw <br>

                          |<br>

| file             | <br>

/v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file <br>

     |<br>

| id               | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 <br>

                          |<br>

| min_disk         | 0 <br>

                          |<br>

| min_ram          | 0 <br>

                          |<br>

| name             | image1 <br>

                          |<br>

| owner            | 826876d6d3724018bae6253c7f540cb3 <br>

                          |<br>

| properties       | locations='[]', os_hash_algo='None', <br>

os_hash_value='None', os_hidden='False' |<br>

| protected        | False <br>

                          |<br>

| schema           | /v2/schemas/image <br>

                          |<br>

| size             | None <br>

                          |<br>

| status           | queued <br>

                          |<br>

| tags             | <br>

                          |<br>

| updated_at       | 2018-10-18T22:17:41Z <br>

                          |<br>

| virtual_size     | None <br>

                          |<br>

| visibility       | private <br>

                          |<br>

+------------------+------------------------------------------------------------------------------+<br>

$ openstack image list<br>

+--------------------------------------+--------+--------+<br>

| ID                                   | Name   | Status |<br>

+--------------------------------------+--------+--------+<br>

| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

| 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |<br>

+--------------------------------------+--------+--------+<br>

$ export OS_USERNAME=user2<br>

$ export OS_PROJECT_NAME=project2<br>

$ openstack image list<br>

+--------------------------------------+--------+--------+<br>

| ID                                   | Name   | Status |<br>

+--------------------------------------+--------+--------+<br>

| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

+--------------------------------------+--------+--------+<br>

$ export OS_USERNAME=admin<br>

$ export OS_PROJECT_NAME=admin<br>

$ export OS_PASSWORD=xxx<br>

$ openstack image set --public 6a0c1928-b79c-4dbf-a9c9-305b599056e4<br>

$ export OS_USERNAME=user2<br>

$ export OS_PROJECT_NAME=project2<br>

$ export OS_PASSWORD=foo<br>

$ openstack image list<br>

+--------------------------------------+--------+--------+<br>

| ID                                   | Name   | Status |<br>

+--------------------------------------+--------+--------+<br>

| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

| 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |<br>

+--------------------------------------+--------+--------+<br>

$<br>

<br>

<br>

On 10/18/2018 03:32 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS <br>

INTEGRA, INC.] wrote:<br>

> openstack user create --domain default --password xxxxxxxx --project-domain ndc --project test mike<br>

> <br>

> <br>

> openstack role add --user mike --user-domain default --project test user<br>

> <br>

> my admin account is in the NDC domain with a different username.<br>

> <br>

> <br>

> <br>

> /etc/glance/policy.json<br>

> {<br>

> <br>

> "context_is_admin":  "role:admin",<br>

> "default": "role:admin",<br>

> <br>

> <snip><br>

> <br>

> <br>

> I'm not terribly familiar with the policies but I feel like that default line is making everyone an admin by default?<br>

> <br>

> <br>

> Mike Moore, M.S.S.E.<br>

>   <br>

> Systems Engineer, Goddard Private Cloud<br>

> Michael.D.Moore@nasa.gov<br>

>   <br>

> Hydrogen fusion brightens my day.<br>

>   <br>

> <br>

> On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

> <br>

>      <br>

>      I suspect that your non-admin user is not really non-admin. How did you<br>

>      create it?<br>

>      <br>

>      What you have for "context_is_admin" in glance's policy.json ?<br>

>      <br>

>           ~iain<br>

>      <br>

>      <br>

>      On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

>      INTEGRA, INC.] wrote:<br>

>      > I have replicated this unexpected behavior in a Pike test environment, in addition to our Queens environment.<br>

>      ><br>

>      ><br>

>      ><br>

>      > Mike Moore, M.S.S.E.<br>

>      ><br>

>      > Systems Engineer, Goddard Private Cloud<br>

>      > Michael.D.Moore@nasa.gov<br>

>      ><br>

>      > Hydrogen fusion brightens my day.<br>

>      ><br>

>      ><br>

>      > On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore@nasa.gov> wrote:<br>

>      ><br>

>      >      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.<br>

>      ><br>

>      >      In the database I can see that the image is 'private' and the owner is the ID of the admin tenant.<br>

>      ><br>

>      >      Mike Moore, M.S.S.E.<br>

>      ><br>

>      >      Systems Engineer, Goddard Private Cloud<br>

>      >      Michael.D.Moore@nasa.gov<br>

>      ><br>

>      >      Hydrogen fusion brightens my day.<br>

>      ><br>

>      ><br>

>      >      On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

>      ><br>

>      ><br>

>      ><br>

>      >          On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

>      >          INTEGRA, INC.] wrote:<br>

>      >          > I’m seeing unexpected behavior in our Queens environment related to<br>

>      >          > Glance image visibility. Specifically users who, based on my<br>

>      >          > understanding of the visibility and ownership fields, should NOT be able<br>

>      >          > to see or view the image.<br>

>      >          ><br>

>      >          > If I create a new image with openstack image create and specify –project<br>

>      >          > <tenant> and –private a non-admin user in a different tenant can see and<br>

>      >          > boot that image.<br>

>      >          ><br>

>      >          > That seems to be the opposite of what should happen. Any ideas?<br>

>      ><br>

>      >          Yep, something's not right there.<br>

>      ><br>

>      >          Are you sure that the user that can see the image doesn't have the admin<br>

>      >          role (for the project in its keystone token) ?<br>

>      ><br>

>      >          Did you verify that the image's owner is what you intended, and that the<br>

>      >          visibility really is "private" ?<br>

>      ><br>

>      >               ~iain<br>

>      ><br>

>      >          _______________________________________________<br>

>      >          OpenStack-operators mailing list<br>

>      >          OpenStack-operators@lists.openstack.org<br>

>      >          <a href="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=" target="_blank">

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=</a><br>

>      ><br>

>      ><br>

>      >      _______________________________________________<br>

>      >      OpenStack-operators mailing list<br>

>      >      OpenStack-operators@lists.openstack.org<br>

>      >      <a href="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=" target="_blank">

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=</a><br>

>      ><br>

>      ><br>

>      <br>

> <br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 7<br>

Date: Thu, 18 Oct 2018 19:23:42 -0400<br>

From: Chris Apsey <bitskrieg@bitskrieg.net><br>

To: iain MacDonnell <iain.macdonnell@oracle.com>, "Moore, Michael Dane<br>

        (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore@nasa.gov>,<br>

        <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -<br>

        Non     admin users can see private images from other tenants<br>

Message-ID:<br>

        <166897de830.278c.5f0d7f2baa7831a2bbe6450f254d9a24@bitskrieg.net><br>

Content-Type: text/plain; format=flowed; charset="UTF-8"<br>

<br>

We are using multiple keystone domains - still can't reproduce this.<br>

<br>

Do you happen to have a customized keystone policy.json?<br>

<br>

Worst case, I would launch a devstack of your targeted release.  If you <br>

can't reproduce the issue there, you would at least know its caused by a <br>

nonstandard config rather than a bug (or at least not a bug that's present <br>

when using a default config)<br>

<br>

On October 18, 2018 18:50:12 iain MacDonnell <iain.macdonnell@oracle.com> <br>

wrote:<br>

<br>

> That all looks fine.<br>

><br>

> I believe that the "default" policy applies in place of any that's not<br>

> explicitly specified - i.e. "if there's no matching policy below, you<br>

> need to have the admin role to be able to do it". I do have that line in<br>

> my policy.json, and I cannot reproduce your problem (see below).<br>

><br>

> I'm not using domains (other than "default"). I wonder if that's a factor...<br>

><br>

>     ~iain<br>

><br>

><br>

> $ openstack user create --password foo user1<br>

> +---------------------+----------------------------------+<br>

> | Field               | Value                            |<br>

> +---------------------+----------------------------------+<br>

> | domain_id           | default                          |<br>

> | enabled             | True                             |<br>

> | id                  | d18c0031ec56430499a2d690cb1f125c |<br>

> | name                | user1                            |<br>

> | options             | {}                               |<br>

> | password_expires_at | None                             |<br>

> +---------------------+----------------------------------+<br>

> $ openstack user create --password foo user2<br>

> +---------------------+----------------------------------+<br>

> | Field               | Value                            |<br>

> +---------------------+----------------------------------+<br>

> | domain_id           | default                          |<br>

> | enabled             | True                             |<br>

> | id                  | be9f1061a5104abd834eabe98dff055d |<br>

> | name                | user2                            |<br>

> | options             | {}                               |<br>

> | password_expires_at | None                             |<br>

> +---------------------+----------------------------------+<br>

> $ openstack project create project1<br>

> +-------------+----------------------------------+<br>

> | Field       | Value                            |<br>

> +-------------+----------------------------------+<br>

> | description |                                  |<br>

> | domain_id   | default                          |<br>

> | enabled     | True                             |<br>

> | id          | 826876d6d3724018bae6253c7f540cb3 |<br>

> | is_domain   | False                            |<br>

> | name        | project1                         |<br>

> | parent_id   | default                          |<br>

> | tags        | []                               |<br>

> +-------------+----------------------------------+<br>

> $ openstack project create project2<br>

> +-------------+----------------------------------+<br>

> | Field       | Value                            |<br>

> +-------------+----------------------------------+<br>

> | description |                                  |<br>

> | domain_id   | default                          |<br>

> | enabled     | True                             |<br>

> | id          | b446b93ac6e24d538c1943acbdd13cb2 |<br>

> | is_domain   | False                            |<br>

> | name        | project2                         |<br>

> | parent_id   | default                          |<br>

> | tags        | []                               |<br>

> +-------------+----------------------------------+<br>

> $ openstack role add --user user1 --project project1 _member_<br>

> $ openstack role add --user user2 --project project2 _member_<br>

> $ export OS_PASSWORD=foo<br>

> $ export OS_USERNAME=user1<br>

> $ export OS_PROJECT_NAME=project1<br>

> $ openstack image list<br>

> +--------------------------------------+--------+--------+<br>

> | ID                                   | Name   | Status |<br>

> +--------------------------------------+--------+--------+<br>

> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

> +--------------------------------------+--------+--------+<br>

> $ openstack image create --private image1<br>

> +------------------+------------------------------------------------------------------------------+<br>

> | Field            | Value<br>

>                          |<br>

> +------------------+------------------------------------------------------------------------------+<br>

> | checksum         | None<br>

>                          |<br>

> | container_format | bare<br>

>                          |<br>

> | created_at       | 2018-10-18T22:17:41Z<br>

>                          |<br>

> | disk_format      | raw<br>

>                          |<br>

> | file             |<br>

> /v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file<br>

>     |<br>

> | id               | 6a0c1928-b79c-4dbf-a9c9-305b599056e4<br>

>                          |<br>

> | min_disk         | 0<br>

>                          |<br>

> | min_ram          | 0<br>

>                          |<br>

> | name             | image1<br>

>                          |<br>

> | owner            | 826876d6d3724018bae6253c7f540cb3<br>

>                          |<br>

> | properties       | locations='[]', os_hash_algo='None',<br>

> os_hash_value='None', os_hidden='False' |<br>

> | protected        | False<br>

>                          |<br>

> | schema           | /v2/schemas/image<br>

>                          |<br>

> | size             | None<br>

>                          |<br>

> | status           | queued<br>

>                          |<br>

> | tags             |<br>

>                          |<br>

> | updated_at       | 2018-10-18T22:17:41Z<br>

>                          |<br>

> | virtual_size     | None<br>

>                          |<br>

> | visibility       | private<br>

>                          |<br>

> +------------------+------------------------------------------------------------------------------+<br>

> $ openstack image list<br>

> +--------------------------------------+--------+--------+<br>

> | ID                                   | Name   | Status |<br>

> +--------------------------------------+--------+--------+<br>

> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

> | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |<br>

> +--------------------------------------+--------+--------+<br>

> $ export OS_USERNAME=user2<br>

> $ export OS_PROJECT_NAME=project2<br>

> $ openstack image list<br>

> +--------------------------------------+--------+--------+<br>

> | ID                                   | Name   | Status |<br>

> +--------------------------------------+--------+--------+<br>

> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

> +--------------------------------------+--------+--------+<br>

> $ export OS_USERNAME=admin<br>

> $ export OS_PROJECT_NAME=admin<br>

> $ export OS_PASSWORD=xxx<br>

> $ openstack image set --public 6a0c1928-b79c-4dbf-a9c9-305b599056e4<br>

> $ export OS_USERNAME=user2<br>

> $ export OS_PROJECT_NAME=project2<br>

> $ export OS_PASSWORD=foo<br>

> $ openstack image list<br>

> +--------------------------------------+--------+--------+<br>

> | ID                                   | Name   | Status |<br>

> +--------------------------------------+--------+--------+<br>

> | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

> | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |<br>

> +--------------------------------------+--------+--------+<br>

> $<br>

><br>

><br>

> On 10/18/2018 03:32 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

> INTEGRA, INC.] wrote:<br>

>> openstack user create --domain default --password xxxxxxxx --project-domain <br>

>> ndc --project test mike<br>

>><br>

>><br>

>> openstack role add --user mike --user-domain default --project test user<br>

>><br>

>> my admin account is in the NDC domain with a different username.<br>

>><br>

>><br>

>><br>

>> /etc/glance/policy.json<br>

>> {<br>

>><br>

>> "context_is_admin":  "role:admin",<br>

>> "default": "role:admin",<br>

>><br>

>> <snip><br>

>><br>

>><br>

>> I'm not terribly familiar with the policies but I feel like that default <br>

>> line is making everyone an admin by default?<br>

>><br>

>><br>

>> Mike Moore, M.S.S.E.<br>

>><br>

>> Systems Engineer, Goddard Private Cloud<br>

>> Michael.D.Moore@nasa.gov<br>

>><br>

>> Hydrogen fusion brightens my day.<br>

>><br>

>><br>

>> On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

>><br>

>><br>

>> I suspect that your non-admin user is not really non-admin. How did you<br>

>> create it?<br>

>><br>

>> What you have for "context_is_admin" in glance's policy.json ?<br>

>><br>

>>  ~iain<br>

>><br>

>><br>

>> On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

>> INTEGRA, INC.] wrote:<br>

>>> I have replicated this unexpected behavior in a Pike test environment, in <br>

>>> addition to our Queens environment.<br>

>>><br>

>>><br>

>>><br>

>>> Mike Moore, M.S.S.E.<br>

>>><br>

>>> Systems Engineer, Goddard Private Cloud<br>

>>> Michael.D.Moore@nasa.gov<br>

>>><br>

>>> Hydrogen fusion brightens my day.<br>

>>><br>

>>><br>

>>> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, <br>

>>> INC.]" <michael.d.moore@nasa.gov> wrote:<br>

>>><br>

>>>    Yes. I verified it by creating a non-admin user in a different tenant. I <br>

>>>    created a new image, set to private with the project defined as our admin <br>

>>>    tenant.<br>

>>><br>

>>>    In the database I can see that the image is 'private' and the owner is the

<br>

>>>    ID of the admin tenant.<br>

>>><br>

>>>    Mike Moore, M.S.S.E.<br>

>>><br>

>>>    Systems Engineer, Goddard Private Cloud<br>

>>>    Michael.D.Moore@nasa.gov<br>

>>><br>

>>>    Hydrogen fusion brightens my day.<br>

>>><br>

>>><br>

>>>    On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

>>><br>

>>><br>

>>><br>

>>>        On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

>>>        INTEGRA, INC.] wrote:<br>

>>>        > I’m seeing unexpected behavior in our Queens environment related to<br>

>>>        > Glance image visibility. Specifically users who, based on my<br>

>>>        > understanding of the visibility and ownership fields, should NOT be able<br>

>>>        > to see or view the image.<br>

>>>        ><br>

>>>        > If I create a new image with openstack image create and specify –project<br>

>>>        > <tenant> and –private a non-admin user in a different tenant can see and<br>

>>>        > boot that image.<br>

>>>        ><br>

>>>        > That seems to be the opposite of what should happen. Any ideas?<br>

>>><br>

>>>        Yep, something's not right there.<br>

>>><br>

>>>        Are you sure that the user that can see the image doesn't have the admin<br>

>>>        role (for the project in its keystone token) ?<br>

>>><br>

>>>        Did you verify that the image's owner is what you intended, and that the<br>

>>>        visibility really is "private" ?<br>

>>><br>

>>>             ~iain<br>

>>><br>

>>>        _______________________________________________<br>

>>>        OpenStack-operators mailing list<br>

>>>        OpenStack-operators@lists.openstack.org<br>

>>>        <a href="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=" target="_blank">

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=</a><br>

>>><br>

>>><br>

>>>    _______________________________________________<br>

>>>    OpenStack-operators mailing list<br>

>>>    OpenStack-operators@lists.openstack.org<br>

>>>    <a href="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=" target="_blank">

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=</a><br>

><br>

> _______________________________________________<br>

> OpenStack-operators mailing list<br>

> OpenStack-operators@lists.openstack.org<br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

<br>

<br>

<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 8<br>

Date: Fri, 19 Oct 2018 10:58:30 +0200<br>

From: Tomáš Vondra <vondra@homeatcloud.cz><br>

To: <OpenStack-operators@lists.openstack.org><br>

Subject: [Openstack-operators] osops-tools-monitoring Dependency<br>

        problems<br>

Message-ID: <049e01d46789$e8bf5220$ba3df660$@homeatcloud.cz><br>

Content-Type: text/plain;       charset="iso-8859-2"<br>

<br>

Hi!<br>

I'm a long time user of monitoring-for-openstack, also known as oschecks.<br>

Concretely, I used a version from 2015 with OpenStack python client<br>

libraries from Kilo. Now I have upgraded them to Mitaka and it got broken.<br>

Even the latest oschecks don't work. I didn't quite expect that, given that<br>

there are several commits from this year e.g. by Nagasai Vinaykumar<br>

Kapalavai and paramite. Can one of them or some other user step up and say<br>

what version of OpenStack clients is oschecks working with? Ideally, write<br>

it down in requirements.txt so that it will be reproducible? Also, some<br>

documentation of what is the minimal set of parameters would also come in<br>

handy.<br>

Thanks a lot, Tomas from Homeatcloud<br>

<br>

The error messages are as absurd as:<br>

oschecks-check_glance_api --os_auth_url='<a href="http://10.1.101.30:5000/v2.0" target="_blank">http://10.1.101.30:5000/v2.0</a>'<br>

--os_username=monitoring --os_password=XXX --os_tenant_name=monitoring<br>

<br>

CRITICAL: Traceback (most recent call last):<br>

  File "/usr/lib/python2.7/dist-packages/oschecks/utils.py", line 121, in<br>

safe_run<br>

    method()<br>

  File "/usr/lib/python2.7/dist-packages/oschecks/glance.py", line 29, in<br>

_check_glance_api<br>

    glance = utils.Glance()<br>

  File "/usr/lib/python2.7/dist-packages/oschecks/utils.py", line 177, in<br>

__init__<br>

    self.glance.parser = self.glance.get_base_parser(sys.argv)<br>

TypeError: get_base_parser() takes exactly 1 argument (2 given)<br>

<br>

(I can see 4 parameters on the command line.)<br>

<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 9<br>

Date: Fri, 19 Oct 2018 11:21:25 +0200<br>

From: Christian Zunker <christian.zunker@codecentric.cloud><br>

To: openstack-operators <openstack-operators@lists.openstack.org><br>

Subject: [Openstack-operators] [heat][cinder] How to create stack<br>

        snapshot        including volumes<br>

Message-ID:<br>

        <CAHS=D_ZGow+hSPuiicq6z0UrRCb3DxC4hf425uY7+5+Rt+-z5w@mail.gmail.com><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

Hi List,<br>

<br>

I'd like to take snapshots of heat stacks including the volumes.<br>

>From what I found until now, this should be possible. You just have to<br>

configure some parts of OpenStack.<br>

<br>

I enabled cinder-backup with ceph backend. Backups from volumes are working.<br>

I configured heat to include the option backups_enabled = True.<br>

<br>

When I use openstack stack snapshot create, I get a snapshot but no backups<br>

of my volumes. I don't get any error messages in heat. Debug logging didn't<br>

help either.<br>

<br>

OpenStack version is Pike on Ubuntu installed with openstack-ansible.<br>

heat version is 9.0.3. So this should also include this bugfix:<br>

<a href="https://bugs.launchpad.net/heat/+bug/1687006" target="_blank">https://bugs.launchpad.net/heat/+bug/1687006</a><br>

<br>

Is anybody using this feature? What am I missing?<br>

<br>

Best regards<br>

Christian<br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20181019/bb7dd81b/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/attachments/20181019/bb7dd81b/attachment-0001.html</a>><br>

<br>

------------------------------<br>

<br>

Message: 10<br>

Date: Fri, 19 Oct 2018 12:42:00 +0300<br>

From: Adrian Andreias <adrian@fleio.com><br>

To: openstack-operators@lists.openstack.org<br>

Subject: [Openstack-operators] Fleio - OpenStack billing - ver. 1.1<br>

        released<br>

Message-ID:<br>

        <CACp-FE3gEP=nwXRtwy-H13qXrnhPa5bn0uWiukxWp=YTU-4e8A@mail.gmail.com><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

Hello,<br>

<br>

We've just released Fleio version 1.1.<br>

<br>

Fleio is a billing solution and control panel for OpenStack public clouds<br>

and traditional web hosters.<br>

<br>

Fleio software automates the entire process for cloud users. New customers<br>

can use Fleio to sign up for an account, pay invoices, add credit to their<br>

account, as well as create and manage cloud resources such as virtual<br>

machines, storage and networking.<br>

<br>

Full feature list:<br>

<a href="https://fleio.com#features" target="_blank">https://fleio.com#features</a><br>

<br>

You can see an online demo:<br>

<a href="https://fleio.com/demo" target="_blank">https://fleio.com/demo</a><br>

<br>

And sign-up for a free trial:<br>

<a href="https://fleio.com/signup" target="_blank">https://fleio.com/signup</a><br>

<br>

<br>

<br>

Cheers!<br>

<br>

- Adrian Andreias<br>

<a href="https://fleio.com" target="_blank">https://fleio.com</a><br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20181019/3031e47f/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/attachments/20181019/3031e47f/attachment-0001.html</a>><br>

<br>

------------------------------<br>

<br>

Message: 11<br>

Date: Fri, 19 Oct 2018 20:54:29 +1100<br>

From: Tony Breeds <tony@bakeyournoodle.com><br>

To: OpenStack Development <openstack-dev@lists.openstack.org>,<br>

        OpenStack SIGs <openstack-sigs@lists.openstack.org>, OpenStack<br>

        Operators <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] [Openstack-sigs] [all] Naming the T<br>

        release of OpenStack<br>

Message-ID: <20181019095428.GA9399@thor.bakeyournoodle.com><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

On Thu, Oct 18, 2018 at 05:35:39PM +1100, Tony Breeds wrote:<br>

> Hello all,<br>

>     As per [1] the nomination period for names for the T release have<br>

> now closed (actually 3 days ago sorry).  The nominated names and any<br>

> qualifying remarks can be seen at2].<br>

> <br>

> Proposed Names<br>

>  * Tarryall<br>

>  * Teakettle<br>

>  * Teller<br>

>  * Telluride<br>

>  * Thomas<br>

>  * Thornton<br>

>  * Tiger<br>

>  * Tincup<br>

>  * Timnath<br>

>  * Timber<br>

>  * Tiny Town<br>

>  * Torreys<br>

>  * Trail<br>

>  * Trinidad<br>

>  * Treasure<br>

>  * Troublesome<br>

>  * Trussville<br>

>  * Turret<br>

>  * Tyrone<br>

> <br>

> Proposed Names that do not meet the criteria<br>

>  * Train<br>

<br>

I have re-worked my openstack/governance change[1] to ask the TC to accept<br>

adding Train to the poll as (partially) described in [2].<br>

<br>

I present the names above to the community and Foundation marketing team<br>

for consideration.  The list above does contain Train, clearly if the TC<br>

do not approve [1] Train will not be included in the poll when created.<br>

<br>

I apologise for any offence or slight caused by my previous email in<br>

this thread.  It was well intentioned albeit, with hindsight, poorly<br>

thought through.<br>

<br>

Yours Tony.<br>

<br>

[1] <a href="https://review.openstack.org/#/c/611511/" target="_blank">https://review.openstack.org/#/c/611511/</a><br>

[2] <a href="https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria" target="_blank">

https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria</a><br>

-------------- next part --------------<br>

A non-text attachment was scrubbed...<br>

Name: signature.asc<br>

Type: application/pgp-signature<br>

Size: 488 bytes<br>

Desc: not available<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20181019/49c95d5d/attachment-0001.sig" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/attachments/20181019/49c95d5d/attachment-0001.sig</a>><br>

<br>

------------------------------<br>

<br>

Message: 12<br>

Date: Fri, 19 Oct 2018 16:33:17 +0000<br>

From: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"<br>

        <michael.d.moore@nasa.gov><br>

To: Chris Apsey <bitskrieg@bitskrieg.net>, iain MacDonnell<br>

        <iain.macdonnell@oracle.com>,<br>

        "openstack-operators@lists.openstack.org"<br>

        <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -<br>

        Non admin users can see private images from other tenants<br>

Message-ID: <4704898B-D193-4540-B106-BF38ACAB68E2@nasa.gov><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

Our NDC domain is LDAP backed. Default is not.<br>

<br>

Our keystone policy.json file is empty {}<br>

<br>

<br>

<br>

Mike Moore, M.S.S.E.<br>

 <br>

Systems Engineer, Goddard Private Cloud<br>

Michael.D.Moore@nasa.gov<br>

 <br>

Hydrogen fusion brightens my day.<br>

 <br>

<br>

On 10/18/18, 7:24 PM, "Chris Apsey" <bitskrieg@bitskrieg.net> wrote:<br>

<br>

    We are using multiple keystone domains - still can't reproduce this.<br>

    <br>

    Do you happen to have a customized keystone policy.json?<br>

    <br>

    Worst case, I would launch a devstack of your targeted release.  If you <br>

    can't reproduce the issue there, you would at least know its caused by a <br>

    nonstandard config rather than a bug (or at least not a bug that's present <br>

    when using a default config)<br>

    <br>

    On October 18, 2018 18:50:12 iain MacDonnell <iain.macdonnell@oracle.com> <br>

    wrote:<br>

    <br>

    > That all looks fine.<br>

    ><br>

    > I believe that the "default" policy applies in place of any that's not<br>

    > explicitly specified - i.e. "if there's no matching policy below, you<br>

    > need to have the admin role to be able to do it". I do have that line in<br>

    > my policy.json, and I cannot reproduce your problem (see below).<br>

    ><br>

    > I'm not using domains (other than "default"). I wonder if that's a factor...<br>

    ><br>

    >     ~iain<br>

    ><br>

    ><br>

    > $ openstack user create --password foo user1<br>

    > +---------------------+----------------------------------+<br>

    > | Field               | Value                            |<br>

    > +---------------------+----------------------------------+<br>

    > | domain_id           | default                          |<br>

    > | enabled             | True                             |<br>

    > | id                  | d18c0031ec56430499a2d690cb1f125c |<br>

    > | name                | user1                            |<br>

    > | options             | {}                               |<br>

    > | password_expires_at | None                             |<br>

    > +---------------------+----------------------------------+<br>

    > $ openstack user create --password foo user2<br>

    > +---------------------+----------------------------------+<br>

    > | Field               | Value                            |<br>

    > +---------------------+----------------------------------+<br>

    > | domain_id           | default                          |<br>

    > | enabled             | True                             |<br>

    > | id                  | be9f1061a5104abd834eabe98dff055d |<br>

    > | name                | user2                            |<br>

    > | options             | {}                               |<br>

    > | password_expires_at | None                             |<br>

    > +---------------------+----------------------------------+<br>

    > $ openstack project create project1<br>

    > +-------------+----------------------------------+<br>

    > | Field       | Value                            |<br>

    > +-------------+----------------------------------+<br>

    > | description |                                  |<br>

    > | domain_id   | default                          |<br>

    > | enabled     | True                             |<br>

    > | id          | 826876d6d3724018bae6253c7f540cb3 |<br>

    > | is_domain   | False                            |<br>

    > | name        | project1                         |<br>

    > | parent_id   | default                          |<br>

    > | tags        | []                               |<br>

    > +-------------+----------------------------------+<br>

    > $ openstack project create project2<br>

    > +-------------+----------------------------------+<br>

    > | Field       | Value                            |<br>

    > +-------------+----------------------------------+<br>

    > | description |                                  |<br>

    > | domain_id   | default                          |<br>

    > | enabled     | True                             |<br>

    > | id          | b446b93ac6e24d538c1943acbdd13cb2 |<br>

    > | is_domain   | False                            |<br>

    > | name        | project2                         |<br>

    > | parent_id   | default                          |<br>

    > | tags        | []                               |<br>

    > +-------------+----------------------------------+<br>

    > $ openstack role add --user user1 --project project1 _member_<br>

    > $ openstack role add --user user2 --project project2 _member_<br>

    > $ export OS_PASSWORD=foo<br>

    > $ export OS_USERNAME=user1<br>

    > $ export OS_PROJECT_NAME=project1<br>

    > $ openstack image list<br>

    > +--------------------------------------+--------+--------+<br>

    > | ID                                   | Name   | Status |<br>

    > +--------------------------------------+--------+--------+<br>

    > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

    > +--------------------------------------+--------+--------+<br>

    > $ openstack image create --private image1<br>

    > +------------------+------------------------------------------------------------------------------+<br>

    > | Field            | Value<br>

    >                          |<br>

    > +------------------+------------------------------------------------------------------------------+<br>

    > | checksum         | None<br>

    >                          |<br>

    > | container_format | bare<br>

    >                          |<br>

    > | created_at       | 2018-10-18T22:17:41Z<br>

    >                          |<br>

    > | disk_format      | raw<br>

    >                          |<br>

    > | file             |<br>

    > /v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file<br>

    >     |<br>

    > | id               | 6a0c1928-b79c-4dbf-a9c9-305b599056e4<br>

    >                          |<br>

    > | min_disk         | 0<br>

    >                          |<br>

    > | min_ram          | 0<br>

    >                          |<br>

    > | name             | image1<br>

    >                          |<br>

    > | owner            | 826876d6d3724018bae6253c7f540cb3<br>

    >                          |<br>

    > | properties       | locations='[]', os_hash_algo='None',<br>

    > os_hash_value='None', os_hidden='False' |<br>

    > | protected        | False<br>

    >                          |<br>

    > | schema           | /v2/schemas/image<br>

    >                          |<br>

    > | size             | None<br>

    >                          |<br>

    > | status           | queued<br>

    >                          |<br>

    > | tags             |<br>

    >                          |<br>

    > | updated_at       | 2018-10-18T22:17:41Z<br>

    >                          |<br>

    > | virtual_size     | None<br>

    >                          |<br>

    > | visibility       | private<br>

    >                          |<br>

    > +------------------+------------------------------------------------------------------------------+<br>

    > $ openstack image list<br>

    > +--------------------------------------+--------+--------+<br>

    > | ID                                   | Name   | Status |<br>

    > +--------------------------------------+--------+--------+<br>

    > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

    > | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |<br>

    > +--------------------------------------+--------+--------+<br>

    > $ export OS_USERNAME=user2<br>

    > $ export OS_PROJECT_NAME=project2<br>

    > $ openstack image list<br>

    > +--------------------------------------+--------+--------+<br>

    > | ID                                   | Name   | Status |<br>

    > +--------------------------------------+--------+--------+<br>

    > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

    > +--------------------------------------+--------+--------+<br>

    > $ export OS_USERNAME=admin<br>

    > $ export OS_PROJECT_NAME=admin<br>

    > $ export OS_PASSWORD=xxx<br>

    > $ openstack image set --public 6a0c1928-b79c-4dbf-a9c9-305b599056e4<br>

    > $ export OS_USERNAME=user2<br>

    > $ export OS_PROJECT_NAME=project2<br>

    > $ export OS_PASSWORD=foo<br>

    > $ openstack image list<br>

    > +--------------------------------------+--------+--------+<br>

    > | ID                                   | Name   | Status |<br>

    > +--------------------------------------+--------+--------+<br>

    > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

    > | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |<br>

    > +--------------------------------------+--------+--------+<br>

    > $<br>

    ><br>

    ><br>

    > On 10/18/2018 03:32 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

    > INTEGRA, INC.] wrote:<br>

    >> openstack user create --domain default --password xxxxxxxx --project-domain

<br>

    >> ndc --project test mike<br>

    >><br>

    >><br>

    >> openstack role add --user mike --user-domain default --project test user<br>

    >><br>

    >> my admin account is in the NDC domain with a different username.<br>

    >><br>

    >><br>

    >><br>

    >> /etc/glance/policy.json<br>

    >> {<br>

    >><br>

    >> "context_is_admin":  "role:admin",<br>

    >> "default": "role:admin",<br>

    >><br>

    >> <snip><br>

    >><br>

    >><br>

    >> I'm not terribly familiar with the policies but I feel like that default <br>

    >> line is making everyone an admin by default?<br>

    >><br>

    >><br>

    >> Mike Moore, M.S.S.E.<br>

    >><br>

    >> Systems Engineer, Goddard Private Cloud<br>

    >> Michael.D.Moore@nasa.gov<br>

    >><br>

    >> Hydrogen fusion brightens my day.<br>

    >><br>

    >><br>

    >> On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

    >><br>

    >><br>

    >> I suspect that your non-admin user is not really non-admin. How did you<br>

    >> create it?<br>

    >><br>

    >> What you have for "context_is_admin" in glance's policy.json ?<br>

    >><br>

    >>  ~iain<br>

    >><br>

    >><br>

    >> On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

    >> INTEGRA, INC.] wrote:<br>

    >>> I have replicated this unexpected behavior in a Pike test environment, in

<br>

    >>> addition to our Queens environment.<br>

    >>><br>

    >>><br>

    >>><br>

    >>> Mike Moore, M.S.S.E.<br>

    >>><br>

    >>> Systems Engineer, Goddard Private Cloud<br>

    >>> Michael.D.Moore@nasa.gov<br>

    >>><br>

    >>> Hydrogen fusion brightens my day.<br>

    >>><br>

    >>><br>

    >>> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA,

<br>

    >>> INC.]" <michael.d.moore@nasa.gov> wrote:<br>

    >>><br>

    >>>    Yes. I verified it by creating a non-admin user in a different tenant. I

<br>

    >>>    created a new image, set to private with the project defined as our admin

<br>

    >>>    tenant.<br>

    >>><br>

    >>>    In the database I can see that the image is 'private' and the owner is the

<br>

    >>>    ID of the admin tenant.<br>

    >>><br>

    >>>    Mike Moore, M.S.S.E.<br>

    >>><br>

    >>>    Systems Engineer, Goddard Private Cloud<br>

    >>>    Michael.D.Moore@nasa.gov<br>

    >>><br>

    >>>    Hydrogen fusion brightens my day.<br>

    >>><br>

    >>><br>

    >>>    On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

    >>><br>

    >>><br>

    >>><br>

    >>>        On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

    >>>        INTEGRA, INC.] wrote:<br>

    >>>        > I’m seeing unexpected behavior in our Queens environment related to<br>

    >>>        > Glance image visibility. Specifically users who, based on my<br>

    >>>        > understanding of the visibility and ownership fields, should NOT be able<br>

    >>>        > to see or view the image.<br>

    >>>        ><br>

    >>>        > If I create a new image with openstack image create and specify –project<br>

    >>>        > <tenant> and –private a non-admin user in a different tenant can see and<br>

    >>>        > boot that image.<br>

    >>>        ><br>

    >>>        > That seems to be the opposite of what should happen. Any ideas?<br>

    >>><br>

    >>>        Yep, something's not right there.<br>

    >>><br>

    >>>        Are you sure that the user that can see the image doesn't have the admin<br>

    >>>        role (for the project in its keystone token) ?<br>

    >>><br>

    >>>        Did you verify that the image's owner is what you intended, and that the<br>

    >>>        visibility really is "private" ?<br>

    >>><br>

    >>>             ~iain<br>

    >>><br>

    >>>        _______________________________________________<br>

    >>>        OpenStack-operators mailing list<br>

    >>>        OpenStack-operators@lists.openstack.org<br>

    >>>        <a href="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=" target="_blank">

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=</a><br>

    >>><br>

    >>><br>

    >>>    _______________________________________________<br>

    >>>    OpenStack-operators mailing list<br>

    >>>    OpenStack-operators@lists.openstack.org<br>

    >>>    <a href="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=" target="_blank">

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=</a><br>

    ><br>

    > _______________________________________________<br>

    > OpenStack-operators mailing list<br>

    > OpenStack-operators@lists.openstack.org<br>

    > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

    <br>

    <br>

    <br>

    <br>

<br>

<br>

------------------------------<br>

<br>

Message: 13<br>

Date: Fri, 19 Oct 2018 16:54:12 +0000<br>

From: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]"<br>

        <michael.d.moore@nasa.gov><br>

To: Chris Apsey <bitskrieg@bitskrieg.net>, iain MacDonnell<br>

        <iain.macdonnell@oracle.com>,<br>

        "openstack-operators@lists.openstack.org"<br>

        <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] Glance Image Visibility Issue? -<br>

        Non admin users can see private images from other tenants<br>

Message-ID: <A5FD0CCA-8B13-424D-A8F2-E6ACECF58C23@nasa.gov><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

<br>

For reference, here is our full glance policy.json<br>

<br>

<br>

{<br>

    "context_is_admin":  "role:admin",<br>

    "default": "role:admin",<br>

<br>

    "add_image": "",<br>

    "delete_image": "",<br>

    "get_image": "",<br>

    "get_images": "",<br>

    "modify_image": "",<br>

    "publicize_image": "role:admin",<br>

    "communitize_image": "",<br>

    "copy_from": "",<br>

<br>

    "download_image": "",<br>

    "upload_image": "",<br>

<br>

    "delete_image_location": "",<br>

    "get_image_location": "",<br>

    "set_image_location": "",<br>

<br>

    "add_member": "",<br>

    "delete_member": "",<br>

    "get_member": "",<br>

    "get_members": "",<br>

    "modify_member": "",<br>

<br>

    "manage_image_cache": "role:admin",<br>

<br>

    "get_task": "",<br>

    "get_tasks": "",<br>

    "add_task": "",<br>

    "modify_task": "",<br>

    "tasks_api_access": "role:admin",<br>

<br>

    "deactivate": "",<br>

    "reactivate": "",<br>

<br>

    "get_metadef_namespace": "",<br>

    "get_metadef_namespaces":"",<br>

    "modify_metadef_namespace":"",<br>

    "add_metadef_namespace":"",<br>

<br>

    "get_metadef_object":"",<br>

    "get_metadef_objects":"",<br>

    "modify_metadef_object":"",<br>

    "add_metadef_object":"",<br>

<br>

    "list_metadef_resource_types":"",<br>

    "get_metadef_resource_type":"",<br>

    "add_metadef_resource_type_association":"",<br>

<br>

    "get_metadef_property":"",<br>

    "get_metadef_properties":"",<br>

    "modify_metadef_property":"",<br>

    "add_metadef_property":"",<br>

<br>

    "get_metadef_tag":"",<br>

    "get_metadef_tags":"",<br>

    "modify_metadef_tag":"",<br>

    "add_metadef_tag":"",<br>

    "add_metadef_tags":""<br>

<br>

}<br>

<br>

<br>

Mike Moore, M.S.S.E.<br>

 <br>

Systems Engineer, Goddard Private Cloud<br>

Michael.D.Moore@nasa.gov<br>

 <br>

Hydrogen fusion brightens my day.<br>

 <br>

<br>

On 10/19/18, 12:39 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore@nasa.gov> wrote:<br>

<br>

    Our NDC domain is LDAP backed. Default is not.<br>

    <br>

    Our keystone policy.json file is empty {}<br>

    <br>

    <br>

    <br>

    Mike Moore, M.S.S.E.<br>

     <br>

    Systems Engineer, Goddard Private Cloud<br>

    Michael.D.Moore@nasa.gov<br>

     <br>

    Hydrogen fusion brightens my day.<br>

     <br>

    <br>

    On 10/18/18, 7:24 PM, "Chris Apsey" <bitskrieg@bitskrieg.net> wrote:<br>

    <br>

        We are using multiple keystone domains - still can't reproduce this.<br>

        <br>

        Do you happen to have a customized keystone policy.json?<br>

        <br>

        Worst case, I would launch a devstack of your targeted release.  If you <br>

        can't reproduce the issue there, you would at least know its caused by a <br>

        nonstandard config rather than a bug (or at least not a bug that's present

<br>

        when using a default config)<br>

        <br>

        On October 18, 2018 18:50:12 iain MacDonnell <iain.macdonnell@oracle.com>

<br>

        wrote:<br>

        <br>

        > That all looks fine.<br>

        ><br>

        > I believe that the "default" policy applies in place of any that's not<br>

        > explicitly specified - i.e. "if there's no matching policy below, you<br>

        > need to have the admin role to be able to do it". I do have that line in<br>

        > my policy.json, and I cannot reproduce your problem (see below).<br>

        ><br>

        > I'm not using domains (other than "default"). I wonder if that's a factor...<br>

        ><br>

        >     ~iain<br>

        ><br>

        ><br>

        > $ openstack user create --password foo user1<br>

        > +---------------------+----------------------------------+<br>

        > | Field               | Value                            |<br>

        > +---------------------+----------------------------------+<br>

        > | domain_id           | default                          |<br>

        > | enabled             | True                             |<br>

        > | id                  | d18c0031ec56430499a2d690cb1f125c |<br>

        > | name                | user1                            |<br>

        > | options             | {}                               |<br>

        > | password_expires_at | None                             |<br>

        > +---------------------+----------------------------------+<br>

        > $ openstack user create --password foo user2<br>

        > +---------------------+----------------------------------+<br>

        > | Field               | Value                            |<br>

        > +---------------------+----------------------------------+<br>

        > | domain_id           | default                          |<br>

        > | enabled             | True                             |<br>

        > | id                  | be9f1061a5104abd834eabe98dff055d |<br>

        > | name                | user2                            |<br>

        > | options             | {}                               |<br>

        > | password_expires_at | None                             |<br>

        > +---------------------+----------------------------------+<br>

        > $ openstack project create project1<br>

        > +-------------+----------------------------------+<br>

        > | Field       | Value                            |<br>

        > +-------------+----------------------------------+<br>

        > | description |                                  |<br>

        > | domain_id   | default                          |<br>

        > | enabled     | True                             |<br>

        > | id          | 826876d6d3724018bae6253c7f540cb3 |<br>

        > | is_domain   | False                            |<br>

        > | name        | project1                         |<br>

        > | parent_id   | default                          |<br>

        > | tags        | []                               |<br>

        > +-------------+----------------------------------+<br>

        > $ openstack project create project2<br>

        > +-------------+----------------------------------+<br>

        > | Field       | Value                            |<br>

        > +-------------+----------------------------------+<br>

        > | description |                                  |<br>

        > | domain_id   | default                          |<br>

        > | enabled     | True                             |<br>

        > | id          | b446b93ac6e24d538c1943acbdd13cb2 |<br>

        > | is_domain   | False                            |<br>

        > | name        | project2                         |<br>

        > | parent_id   | default                          |<br>

        > | tags        | []                               |<br>

        > +-------------+----------------------------------+<br>

        > $ openstack role add --user user1 --project project1 _member_<br>

        > $ openstack role add --user user2 --project project2 _member_<br>

        > $ export OS_PASSWORD=foo<br>

        > $ export OS_USERNAME=user1<br>

        > $ export OS_PROJECT_NAME=project1<br>

        > $ openstack image list<br>

        > +--------------------------------------+--------+--------+<br>

        > | ID                                   | Name   | Status |<br>

        > +--------------------------------------+--------+--------+<br>

        > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

        > +--------------------------------------+--------+--------+<br>

        > $ openstack image create --private image1<br>

        > +------------------+------------------------------------------------------------------------------+<br>

        > | Field            | Value<br>

        >                          |<br>

        > +------------------+------------------------------------------------------------------------------+<br>

        > | checksum         | None<br>

        >                          |<br>

        > | container_format | bare<br>

        >                          |<br>

        > | created_at       | 2018-10-18T22:17:41Z<br>

        >                          |<br>

        > | disk_format      | raw<br>

        >                          |<br>

        > | file             |<br>

        > /v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file<br>

        >     |<br>

        > | id               | 6a0c1928-b79c-4dbf-a9c9-305b599056e4<br>

        >                          |<br>

        > | min_disk         | 0<br>

        >                          |<br>

        > | min_ram          | 0<br>

        >                          |<br>

        > | name             | image1<br>

        >                          |<br>

        > | owner            | 826876d6d3724018bae6253c7f540cb3<br>

        >                          |<br>

        > | properties       | locations='[]', os_hash_algo='None',<br>

        > os_hash_value='None', os_hidden='False' |<br>

        > | protected        | False<br>

        >                          |<br>

        > | schema           | /v2/schemas/image<br>

        >                          |<br>

        > | size             | None<br>

        >                          |<br>

        > | status           | queued<br>

        >                          |<br>

        > | tags             |<br>

        >                          |<br>

        > | updated_at       | 2018-10-18T22:17:41Z<br>

        >                          |<br>

        > | virtual_size     | None<br>

        >                          |<br>

        > | visibility       | private<br>

        >                          |<br>

        > +------------------+------------------------------------------------------------------------------+<br>

        > $ openstack image list<br>

        > +--------------------------------------+--------+--------+<br>

        > | ID                                   | Name   | Status |<br>

        > +--------------------------------------+--------+--------+<br>

        > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

        > | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |<br>

        > +--------------------------------------+--------+--------+<br>

        > $ export OS_USERNAME=user2<br>

        > $ export OS_PROJECT_NAME=project2<br>

        > $ openstack image list<br>

        > +--------------------------------------+--------+--------+<br>

        > | ID                                   | Name   | Status |<br>

        > +--------------------------------------+--------+--------+<br>

        > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

        > +--------------------------------------+--------+--------+<br>

        > $ export OS_USERNAME=admin<br>

        > $ export OS_PROJECT_NAME=admin<br>

        > $ export OS_PASSWORD=xxx<br>

        > $ openstack image set --public 6a0c1928-b79c-4dbf-a9c9-305b599056e4<br>

        > $ export OS_USERNAME=user2<br>

        > $ export OS_PROJECT_NAME=project2<br>

        > $ export OS_PASSWORD=foo<br>

        > $ openstack image list<br>

        > +--------------------------------------+--------+--------+<br>

        > | ID                                   | Name   | Status |<br>

        > +--------------------------------------+--------+--------+<br>

        > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |<br>

        > | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued |<br>

        > +--------------------------------------+--------+--------+<br>

        > $<br>

        ><br>

        ><br>

        > On 10/18/2018 03:32 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

        > INTEGRA, INC.] wrote:<br>

        >> openstack user create --domain default --password xxxxxxxx --project-domain

<br>

        >> ndc --project test mike<br>

        >><br>

        >><br>

        >> openstack role add --user mike --user-domain default --project test user<br>

        >><br>

        >> my admin account is in the NDC domain with a different username.<br>

        >><br>

        >><br>

        >><br>

        >> /etc/glance/policy.json<br>

        >> {<br>

        >><br>

        >> "context_is_admin":  "role:admin",<br>

        >> "default": "role:admin",<br>

        >><br>

        >> <snip><br>

        >><br>

        >><br>

        >> I'm not terribly familiar with the policies but I feel like that default

<br>

        >> line is making everyone an admin by default?<br>

        >><br>

        >><br>

        >> Mike Moore, M.S.S.E.<br>

        >><br>

        >> Systems Engineer, Goddard Private Cloud<br>

        >> Michael.D.Moore@nasa.gov<br>

        >><br>

        >> Hydrogen fusion brightens my day.<br>

        >><br>

        >><br>

        >> On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

        >><br>

        >><br>

        >> I suspect that your non-admin user is not really non-admin. How did you<br>

        >> create it?<br>

        >><br>

        >> What you have for "context_is_admin" in glance's policy.json ?<br>

        >><br>

        >>  ~iain<br>

        >><br>

        >><br>

        >> On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

        >> INTEGRA, INC.] wrote:<br>

        >>> I have replicated this unexpected behavior in a Pike test environment, in

<br>

        >>> addition to our Queens environment.<br>

        >>><br>

        >>><br>

        >>><br>

        >>> Mike Moore, M.S.S.E.<br>

        >>><br>

        >>> Systems Engineer, Goddard Private Cloud<br>

        >>> Michael.D.Moore@nasa.gov<br>

        >>><br>

        >>> Hydrogen fusion brightens my day.<br>

        >>><br>

        >>><br>

        >>> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA,

<br>

        >>> INC.]" <michael.d.moore@nasa.gov> wrote:<br>

        >>><br>

        >>>    Yes. I verified it by creating a non-admin user in a different tenant. I

<br>

        >>>    created a new image, set to private with the project defined as our admin

<br>

        >>>    tenant.<br>

        >>><br>

        >>>    In the database I can see that the image is 'private' and the owner is the

<br>

        >>>    ID of the admin tenant.<br>

        >>><br>

        >>>    Mike Moore, M.S.S.E.<br>

        >>><br>

        >>>    Systems Engineer, Goddard Private Cloud<br>

        >>>    Michael.D.Moore@nasa.gov<br>

        >>><br>

        >>>    Hydrogen fusion brightens my day.<br>

        >>><br>

        >>><br>

        >>>    On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonnell@oracle.com> wrote:<br>

        >>><br>

        >>><br>

        >>><br>

        >>>        On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS<br>

        >>>        INTEGRA, INC.] wrote:<br>

        >>>        > I’m seeing unexpected behavior in our Queens environment related to<br>

        >>>        > Glance image visibility. Specifically users who, based on my<br>

        >>>        > understanding of the visibility and ownership fields, should NOT be able<br>

        >>>        > to see or view the image.<br>

        >>>        ><br>

        >>>        > If I create a new image with openstack image create and specify –project<br>

        >>>        > <tenant> and –private a non-admin user in a different tenant can see and<br>

        >>>        > boot that image.<br>

        >>>        ><br>

        >>>        > That seems to be the opposite of what should happen. Any ideas?<br>

        >>><br>

        >>>        Yep, something's not right there.<br>

        >>><br>

        >>>        Are you sure that the user that can see the image doesn't have the admin<br>

        >>>        role (for the project in its keystone token) ?<br>

        >>><br>

        >>>        Did you verify that the image's owner is what you intended, and that the<br>

        >>>        visibility really is "private" ?<br>

        >>><br>

        >>>             ~iain<br>

        >>><br>

        >>>        _______________________________________________<br>

        >>>        OpenStack-operators mailing list<br>

        >>>        OpenStack-operators@lists.openstack.org<br>

        >>>        <a href="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=" target="_blank">

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=</a><br>

        >>><br>

        >>><br>

        >>>    _______________________________________________<br>

        >>>    OpenStack-operators mailing list<br>

        >>>    OpenStack-operators@lists.openstack.org<br>

        >>>    <a href="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=" target="_blank">

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=</a><br>

        ><br>

        > _______________________________________________<br>

        > OpenStack-operators mailing list<br>

        > OpenStack-operators@lists.openstack.org<br>

        > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

        <br>

        <br>

        <br>

        <br>

    <br>

    _______________________________________________<br>

    OpenStack-operators mailing list<br>

    OpenStack-operators@lists.openstack.org<br>

    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

    <br>

<br>

<br>

------------------------------<br>

<br>

Message: 14<br>

Date: Fri, 19 Oct 2018 13:45:03 -0400<br>

From: Jay Pipes <jaypipes@gmail.com><br>

To: openstack-operators@lists.openstack.org<br>

Subject: Re: [Openstack-operators] Fleio - OpenStack billing - ver.<br>

        1.1 released<br>

Message-ID: <b3f680a3-71ef-5c55-6dea-d71c9d973640@gmail.com><br>

Content-Type: text/plain; charset=utf-8; format=flowed<br>

<br>

Please do not use these mailing lists to advertise <br>

closed-source/proprietary software solutions.<br>

<br>

Thank you,<br>

-jay<br>

<br>

On 10/19/2018 05:42 AM, Adrian Andreias wrote:<br>

> Hello,<br>

> <br>

> We've just released Fleio version 1.1.<br>

> <br>

> Fleio is a billing solution and control panel for OpenStack public <br>

> clouds and traditional web hosters.<br>

> <br>

> Fleio software automates the entire process for cloud users. New <br>

> customers can use Fleio to sign up for an account, pay invoices, add <br>

> credit to their account, as well as create and manage cloud resources <br>

> such as virtual machines, storage and networking.<br>

> <br>

> Full feature list:<br>

> <a href="https://fleio.com#features" target="_blank">https://fleio.com#features</a><br>

> <br>

> You can see an online demo:<br>

> <a href="https://fleio.com/demo" target="_blank">https://fleio.com/demo</a><br>

> <br>

> And sign-up for a free trial:<br>

> <a href="https://fleio.com/signup" target="_blank">https://fleio.com/signup</a><br>

> <br>

> <br>

> <br>

> Cheers!<br>

> <br>

> - Adrian Andreias<br>

> <a href="https://fleio.com" target="_blank">https://fleio.com</a><br>

> <br>

> <br>

> <br>

> _______________________________________________<br>

> OpenStack-operators mailing list<br>

> OpenStack-operators@lists.openstack.org<br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

> <br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 15<br>

Date: Fri, 19 Oct 2018 20:13:40 +0200<br>

From: Mohammed Naser <mnaser@vexxhost.com><br>

To: jaypipes@gmail.com<br>

Cc: openstack-operators <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] Fleio - OpenStack billing - ver.<br>

        1.1     released<br>

Message-ID:<br>

        <CAEs876gDHPFjgxnD+HHKyP782u2XX0attJq9dYiYFDibc6DTZQ@mail.gmail.com><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

On Fri, Oct 19, 2018 at 7:45 PM Jay Pipes <jaypipes@gmail.com> wrote:<br>

><br>

> Please do not use these mailing lists to advertise<br>

> closed-source/proprietary software solutions.<br>

<br>

+1<br>

<br>

> Thank you,<br>

> -jay<br>

><br>

> On 10/19/2018 05:42 AM, Adrian Andreias wrote:<br>

> > Hello,<br>

> ><br>

> > We've just released Fleio version 1.1.<br>

> ><br>

> > Fleio is a billing solution and control panel for OpenStack public<br>

> > clouds and traditional web hosters.<br>

> ><br>

> > Fleio software automates the entire process for cloud users. New<br>

> > customers can use Fleio to sign up for an account, pay invoices, add<br>

> > credit to their account, as well as create and manage cloud resources<br>

> > such as virtual machines, storage and networking.<br>

> ><br>

> > Full feature list:<br>

> > <a href="https://fleio.com#features" target="_blank">https://fleio.com#features</a><br>

> ><br>

> > You can see an online demo:<br>

> > <a href="https://fleio.com/demo" target="_blank">https://fleio.com/demo</a><br>

> ><br>

> > And sign-up for a free trial:<br>

> > <a href="https://fleio.com/signup" target="_blank">https://fleio.com/signup</a><br>

> ><br>

> ><br>

> ><br>

> > Cheers!<br>

> ><br>

> > - Adrian Andreias<br>

> > <a href="https://fleio.com" target="_blank">https://fleio.com</a><br>

> ><br>

> ><br>

> ><br>

> > _______________________________________________<br>

> > OpenStack-operators mailing list<br>

> > OpenStack-operators@lists.openstack.org<br>

> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

> ><br>

><br>

> _______________________________________________<br>

> OpenStack-operators mailing list<br>

> OpenStack-operators@lists.openstack.org<br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

<br>

<br>

<br>

-- <br>

Mohammed Naser — vexxhost<br>

-----------------------------------------------------<br>

D. 514-316-8872<br>

D. 800-910-1726 ext. 200<br>

E. mnaser@vexxhost.com<br>

W. <a href="http://vexxhost.com" target="_blank">http://vexxhost.com</a><br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 16<br>

Date: Fri, 19 Oct 2018 14:39:29 -0400<br>

From: Erik McCormick <emccormick@cirrusseven.com><br>

To: openstack-operators <openstack-operators@lists.openstack.org><br>

Subject: [Openstack-operators] [Octavia] SSL errors polling amphorae<br>

        and     missing tenant network interface<br>

Message-ID:<br>

        <CAHUi5cNByYFRr4vHY9iAEhAFc=MhdjhBWHNArCQG0D-w-Z2gFg@mail.gmail.com><br>

Content-Type: text/plain; charset="UTF-8"<br>

<br>

I've been wrestling with getting Octavia up and running and have<br>

become stuck on two issues. I'm hoping someone has run into these<br>

before. My google foo has come up empty.<br>

<br>

Issue 1:<br>

When the Octavia controller tries to poll the amphora instance, it<br>

tries repeatedly and eventually fails. The error on the controller<br>

side is:<br>

<br>

2018-10-19 14:17:39.181 26 ERROR<br>

octavia.amphorae.drivers.haproxy.rest_api_driver [-] Connection<br>

retries (currently set to 300) exhausted.  The amphora is unavailable.<br>

Reason: HTTPSConnectionPool(host='10.7.0.112', port=9443): Max retries<br>

exceeded with url: /0.5/plug/vip/10.250.20.15 (Caused by<br>

SSLError(SSLError("bad handshake: Error([('rsa routines',<br>

'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',<br>

'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding<br>

routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',<br>

'tls_process_server_certificate', 'certificate verify<br>

failed')],)",),)): SSLError: HTTPSConnectionPool(host='10.7.0.112',<br>

port=9443): Max retries exceeded with url: /0.5/plug/vip/10.250.20.15<br>

(Caused by SSLError(SSLError("bad handshake: Error([('rsa routines',<br>

'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',<br>

'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding<br>

routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',<br>

'tls_process_server_certificate', 'certificate verify<br>

failed')],)",),))<br>

<br>

On the amphora side I see:<br>

[2018-10-19 17:52:54 +0000] [1331] [DEBUG] Error processing SSL request.<br>

[2018-10-19 17:52:54 +0000] [1331] [DEBUG] Invalid request from<br>

ip=::ffff:10.7.0.40: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake<br>

failure (_ssl.c:1754)<br>

<br>

I've generated certificates both with the script in the Octavia git<br>

repo, and with the Openstack Ansible playbook. I can see that they are<br>

present in /etc/octavia/certs.<br>

<br>

I'm using the Kolla (Queens) containers for the control plane so I'm<br>

sure I've satisfied all the python library constraints.<br>

<br>

Issue 2:<br>

I"m not sure how it gets configured, but the tenant network interface<br>

(ens6) never comes up. I can spawn other instances on that network<br>

with no issue, and I can see that Neutron has the port attached to the<br>

instance. However, in the instance this is all I get:<br>

<br>

ubuntu@amphora-33e0aab3-8bc4-4fcb-bc42-b9b36afb16d4:~$ ip a<br>

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN<br>

group default qlen 1<br>

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br>

    inet 127.0.0.1/8 scope host lo<br>

       valid_lft forever preferred_lft forever<br>

    inet6 ::1/128 scope host<br>

       valid_lft forever preferred_lft forever<br>

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast<br>

state UP group default qlen 1000<br>

    link/ether fa:16:3e:30:c4:60 brd ff:ff:ff:ff:ff:ff<br>

    inet 10.7.0.112/16 brd 10.7.255.255 scope global ens3<br>

       valid_lft forever preferred_lft forever<br>

    inet6 fe80::f816:3eff:fe30:c460/64 scope link<br>

       valid_lft forever preferred_lft forever<br>

3: ens6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group<br>

default qlen 1000<br>

    link/ether fa:16:3e:89:a2:7f brd ff:ff:ff:ff:ff:ff<br>

<br>

There's no evidence of the interface anywhere else including udev rules.<br>

<br>

Any help with either or both issues would be greatly appreciated.<br>

<br>

Cheers,<br>

Erik<br>

<br>

<br>

<br>

------------------------------<br>

<br>

Message: 17<br>

Date: Sat, 20 Oct 2018 01:47:42 +0200<br>

From: Gaël THEROND <gael.therond@gmail.com><br>

To: Erik McCormick <emccormick@cirrusseven.com><br>

Cc: openstack-operators <openstack-operators@lists.openstack.org><br>

Subject: Re: [Openstack-operators] [Octavia] SSL errors polling<br>

        amphorae and missing tenant network interface<br>

Message-ID:<br>

        <CAG+53ua-Hcjjq=_00rUZNsATmWq7g_8uZbMXAB_9VghtR_ByZA@mail.gmail.com><br>

Content-Type: text/plain; charset="utf-8"<br>

<br>

Hi eric!<br>

<br>

Glad I’m not the only one having this issue with the ssl communication<br>

between the amphora and the CP.<br>

<br>

Even if I don’t yet get a clear answer regarding that issue, I think your<br>

second issue is not an issue as the interface is mounted on a namespace and<br>

so you’ll need to list all nic even those from namespace.<br>

<br>

Use an ip netns ls to get the namespace.<br>

<br>

Hope it will help.<br>

<br>

Le ven. 19 oct. 2018 à 20:40, Erik McCormick <emccormick@cirrusseven.com> a<br>

écrit :<br>

<br>

> I've been wrestling with getting Octavia up and running and have<br>

> become stuck on two issues. I'm hoping someone has run into these<br>

> before. My google foo has come up empty.<br>

><br>

> Issue 1:<br>

> When the Octavia controller tries to poll the amphora instance, it<br>

> tries repeatedly and eventually fails. The error on the controller<br>

> side is:<br>

><br>

> 2018-10-19 14:17:39.181 26 ERROR<br>

> octavia.amphorae.drivers.haproxy.rest_api_driver [-] Connection<br>

> retries (currently set to 300) exhausted.  The amphora is unavailable.<br>

> Reason: HTTPSConnectionPool(host='10.7.0.112', port=9443): Max retries<br>

> exceeded with url: /0.5/plug/vip/10.250.20.15 (Caused by<br>

> SSLError(SSLError("bad handshake: Error([('rsa routines',<br>

> 'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',<br>

> 'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding<br>

> routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',<br>

> 'tls_process_server_certificate', 'certificate verify<br>

> failed')],)",),)): SSLError: HTTPSConnectionPool(host='10.7.0.112',<br>

> port=9443): Max retries exceeded with url: /0.5/plug/vip/10.250.20.15<br>

> (Caused by SSLError(SSLError("bad handshake: Error([('rsa routines',<br>

> 'RSA_padding_check_PKCS1_type_1', 'invalid padding'), ('rsa routines',<br>

> 'rsa_ossl_public_decrypt', 'padding check failed'), ('asn1 encoding<br>

> routines', 'ASN1_item_verify', 'EVP lib'), ('SSL routines',<br>

> 'tls_process_server_certificate', 'certificate verify<br>

> failed')],)",),))<br>

><br>

> On the amphora side I see:<br>

> [2018-10-19 17:52:54 +0000] [1331] [DEBUG] Error processing SSL request.<br>

> [2018-10-19 17:52:54 +0000] [1331] [DEBUG] Invalid request from<br>

> ip=::ffff:10.7.0.40: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake<br>

> failure (_ssl.c:1754)<br>

><br>

> I've generated certificates both with the script in the Octavia git<br>

> repo, and with the Openstack Ansible playbook. I can see that they are<br>

> present in /etc/octavia/certs.<br>

><br>

> I'm using the Kolla (Queens) containers for the control plane so I'm<br>

> sure I've satisfied all the python library constraints.<br>

><br>

> Issue 2:<br>

> I"m not sure how it gets configured, but the tenant network interface<br>

> (ens6) never comes up. I can spawn other instances on that network<br>

> with no issue, and I can see that Neutron has the port attached to the<br>

> instance. However, in the instance this is all I get:<br>

><br>

> ubuntu@amphora-33e0aab3-8bc4-4fcb-bc42-b9b36afb16d4:~$ ip a<br>

> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN<br>

> group default qlen 1<br>

>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br>

>     inet 127.0.0.1/8 scope host lo<br>

>        valid_lft forever preferred_lft forever<br>

>     inet6 ::1/128 scope host<br>

>        valid_lft forever preferred_lft forever<br>

> 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast<br>

> state UP group default qlen 1000<br>

>     link/ether fa:16:3e:30:c4:60 brd ff:ff:ff:ff:ff:ff<br>

>     inet 10.7.0.112/16 brd 10.7.255.255 scope global ens3<br>

>        valid_lft forever preferred_lft forever<br>

>     inet6 fe80::f816:3eff:fe30:c460/64 scope link<br>

>        valid_lft forever preferred_lft forever<br>

> 3: ens6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group<br>

> default qlen 1000<br>

>     link/ether fa:16:3e:89:a2:7f brd ff:ff:ff:ff:ff:ff<br>

><br>

> There's no evidence of the interface anywhere else including udev rules.<br>

><br>

> Any help with either or both issues would be greatly appreciated.<br>

><br>

> Cheers,<br>

> Erik<br>

><br>

> _______________________________________________<br>

> OpenStack-operators mailing list<br>

> OpenStack-operators@lists.openstack.org<br>

> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

><br>

-------------- next part --------------<br>

An HTML attachment was scrubbed...<br>

URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20181020/71c8e27a/attachment.html" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/attachments/20181020/71c8e27a/attachment.html</a>><br>

<br>

------------------------------<br>

<br>

Subject: Digest Footer<br>

<br>

_______________________________________________<br>

OpenStack-operators mailing list<br>

OpenStack-operators@lists.openstack.org<br>

<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>

<br>

<br>

------------------------------<br>

<br>

End of OpenStack-operators Digest, Vol 96, Issue 7<br>

**************************************************<br>

</div>

</span></font></div>

</div>

</div>

</div>

</body>

</html>