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