date:20181018

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

2018-10-18 Thread Chris Apsey


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

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

Worst case, I would launch a devstack of your targeted release.  If you 
can't reproduce the issue there, you would at least know its caused by a 
nonstandard config rather than a bug (or at least not a bug that's present 
when using a default config)


On October 18, 2018 18:50:12 iain MacDonnell  
wrote:



That all looks fine.

I believe that the "default" policy applies in place of any that's not
explicitly specified - i.e. "if there's no matching policy below, you
need to have the admin role to be able to do it". I do have that line in
my policy.json, and I cannot reproduce your problem (see below).

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

~iain


$ openstack user create --password foo user1
+-+--+
| Field   | Value|
+-+--+
| domain_id   | default  |
| enabled | True |
| id  | d18c0031ec56430499a2d690cb1f125c |
| name| user1|
| options | {}   |
| password_expires_at | None |
+-+--+
$ openstack user create --password foo user2
+-+--+
| Field   | Value|
+-+--+
| domain_id   | default  |
| enabled | True |
| id  | be9f1061a5104abd834eabe98dff055d |
| name| user2|
| options | {}   |
| password_expires_at | None |
+-+--+
$ openstack project create project1
+-+--+
| Field   | Value|
+-+--+
| description |  |
| domain_id   | default  |
| enabled | True |
| id  | 826876d6d3724018bae6253c7f540cb3 |
| is_domain   | False|
| name| project1 |
| parent_id   | default  |
| tags| []   |
+-+--+
$ openstack project create project2
+-+--+
| Field   | Value|
+-+--+
| description |  |
| domain_id   | default  |
| enabled | True |
| id  | b446b93ac6e24d538c1943acbdd13cb2 |
| is_domain   | False|
| name| project2 |
| parent_id   | default  |
| tags| []   |
+-+--+
$ openstack role add --user user1 --project project1 _member_
$ openstack role add --user user2 --project project2 _member_
$ export OS_PASSWORD=foo
$ export OS_USERNAME=user1
$ export OS_PROJECT_NAME=project1
$ openstack image list
+--+++
| ID   | Name   | Status |
+--+++
| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
+--+++
$ openstack image create --private image1
+--+--+
| Field| Value
 |
+--+--+
| checksum | None
 |
| container_format | bare
 |
| created_at   | 2018-10-18T22:17:41Z
 |
| disk_format  | raw
 |
| file |
/v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file
|
| id   | 6a0c1928-b79c-4dbf-a9c9-305b599056e4
 |
| min_disk | 0
 |
| min_ram  | 0
 |
| name | image1
 |
| owner| 826876d6d3724018bae6253c7f540cb3
 |
| properties   | locations='[]', os_hash_algo='None',
os_hash_value='None', os_hidden='False' |
| protected| False

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

2018-10-18 Thread iain MacDonnell



That all looks fine.

I believe that the "default" policy applies in place of any that's not 
explicitly specified - i.e. "if there's no matching policy below, you 
need to have the admin role to be able to do it". I do have that line in 
my policy.json, and I cannot reproduce your problem (see below).


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

~iain


$ openstack user create --password foo user1
+-+--+
| Field   | Value|
+-+--+
| domain_id   | default  |
| enabled | True |
| id  | d18c0031ec56430499a2d690cb1f125c |
| name| user1|
| options | {}   |
| password_expires_at | None |
+-+--+
$ openstack user create --password foo user2
+-+--+
| Field   | Value|
+-+--+
| domain_id   | default  |
| enabled | True |
| id  | be9f1061a5104abd834eabe98dff055d |
| name| user2|
| options | {}   |
| password_expires_at | None |
+-+--+
$ openstack project create project1
+-+--+
| Field   | Value|
+-+--+
| description |  |
| domain_id   | default  |
| enabled | True |
| id  | 826876d6d3724018bae6253c7f540cb3 |
| is_domain   | False|
| name| project1 |
| parent_id   | default  |
| tags| []   |
+-+--+
$ openstack project create project2
+-+--+
| Field   | Value|
+-+--+
| description |  |
| domain_id   | default  |
| enabled | True |
| id  | b446b93ac6e24d538c1943acbdd13cb2 |
| is_domain   | False|
| name| project2 |
| parent_id   | default  |
| tags| []   |
+-+--+
$ openstack role add --user user1 --project project1 _member_
$ openstack role add --user user2 --project project2 _member_
$ export OS_PASSWORD=foo
$ export OS_USERNAME=user1
$ export OS_PROJECT_NAME=project1
$ openstack image list
+--+++
| ID   | Name   | Status |
+--+++
| ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active |
+--+++
$ openstack image create --private image1
+--+--+
| Field| Value 
 |

+--+--+
| checksum | None 
 |
| container_format | bare 
 |
| created_at   | 2018-10-18T22:17:41Z 
 |
| disk_format  | raw 
 |
| file | 
/v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file 
|
| id   | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 
 |
| min_disk | 0 
 |
| min_ram  | 0 
 |
| name | image1 
 |
| owner| 826876d6d3724018bae6253c7f540cb3 
 |
| properties   | locations='[]', os_hash_algo='None', 
os_hash_value='None', os_hidden='False' |
| protected| False 
 |
| schema   | /v2/schemas/image 
 |
| size | None 
 |
| status   | queued 
 |
| tags | 
 |
| updated_at   | 2018-10-18T22:17:41Z 
 |
| virtual_size | None 
 |
| visibility   | private 
 |

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

2018-10-18 Thread Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]

openstack user create --domain default --password  --project-domain ndc 
--project test mike


openstack role add --user mike --user-domain default --project test user

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



/etc/glance/policy.json 
{

"context_is_admin":  "role:admin",
"default": "role:admin",




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


Mike Moore, M.S.S.E.
 
Systems Engineer, Goddard Private Cloud
michael.d.mo...@nasa.gov
 
Hydrogen fusion brightens my day.
 

On 10/18/18, 6:25 PM, "iain MacDonnell"  wrote:


I suspect that your non-admin user is not really non-admin. How did you 
create it?

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

 ~iain


On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS 
INTEGRA, INC.] wrote:
> I have replicated this unexpected behavior in a Pike test environment, in 
addition to our Queens environment.
> 
> 
> 
> Mike Moore, M.S.S.E.
>   
> Systems Engineer, Goddard Private Cloud
> michael.d.mo...@nasa.gov
>   
> Hydrogen fusion brightens my day.
>   
> 
> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, 
INC.]"  wrote:
> 
>  Yes. I verified it by creating a non-admin user in a different 
tenant. I created a new image, set to private with the project defined as our 
admin tenant.
>  
>  In the database I can see that the image is 'private' and the owner 
is the ID of the admin tenant.
>  
>  Mike Moore, M.S.S.E.
>   
>  Systems Engineer, Goddard Private Cloud
>  michael.d.mo...@nasa.gov
>   
>  Hydrogen fusion brightens my day.
>   
>  
>  On 10/18/18, 1:07 AM, "iain MacDonnell"  
wrote:
>  
>  
>  
>  On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
>  INTEGRA, INC.] wrote:
>  > I’m seeing unexpected behavior in our Queens environment 
related to
>  > Glance image visibility. Specifically users who, based on my
>  > understanding of the visibility and ownership fields, should 
NOT be able
>  > to see or view the image.
>  >
>  > If I create a new image with openstack image create and 
specify –project
>  >  and –private a non-admin user in a different tenant 
can see and
>  > boot that image.
>  >
>  > That seems to be the opposite of what should happen. Any ideas?
>  
>  Yep, something's not right there.
>  
>  Are you sure that the user that can see the image doesn't have 
the admin
>  role (for the project in its keystone token) ?
>  
>  Did you verify that the image's owner is what you intended, and 
that the
>  visibility really is "private" ?
>  
>   ~iain
>  
>  ___
>  OpenStack-operators mailing list
>  OpenStack-operators@lists.openstack.org
>  
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE=
>  
>  
>  ___
>  OpenStack-operators mailing list
>  OpenStack-operators@lists.openstack.org
>  
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE=
>  
> 


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

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

2018-10-18 Thread iain MacDonnell

I suspect that your non-admin user is not really non-admin. How did you 
create it?

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

~iain

On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS 
INTEGRA, INC.] wrote:

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

Mike Moore, M.S.S.E.

Systems Engineer, Goddard Private Cloud

michael.d.mo...@nasa.gov

Hydrogen fusion brightens my day.

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

 Yes. I verified it by creating a non-admin user in a different tenant. I 
created a new image, set to private with the project defined as our admin 
tenant.

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

 Mike Moore, M.S.S.E.

 Systems Engineer, Goddard Private Cloud

 michael.d.mo...@nasa.gov

 Hydrogen fusion brightens my day.

 On 10/18/18, 1:07 AM, "iain MacDonnell"  wrote:

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

 INTEGRA, INC.] wrote:
 > I’m seeing unexpected behavior in our Queens environment related to
 > Glance image visibility. Specifically users who, based on my
 > understanding of the visibility and ownership fields, should NOT be 
able
 > to see or view the image.
 >
 > If I create a new image with openstack image create and specify 
–project
 >  and –private a non-admin user in a different tenant can see 
and
 > boot that image.
 >
 > That seems to be the opposite of what should happen. Any ideas?

 Yep, something's not right there.

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

 role (for the project in its keystone token) ?

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

 visibility really is "private" ?

  ~iain

 ___

 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE=

 ___

 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE=

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

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

2018-10-18 Thread Chris Apsey

Do you have a liberal/custom policy.json that perhaps is causing unexpected 
behavior?  Can't seem to reproduce this.


On October 18, 2018 18:13:22 "Moore, Michael Dane (GSFC-720.0)[BUSINESS 
INTEGRA, INC.]"  wrote:


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




Mike Moore, M.S.S.E.

Systems Engineer, Goddard Private Cloud
michael.d.mo...@nasa.gov

Hydrogen fusion brightens my day.


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


   Yes. I verified it by creating a non-admin user in a different tenant. I 
   created a new image, set to private with the project defined as our admin 
   tenant.


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


   Mike Moore, M.S.S.E.

   Systems Engineer, Goddard Private Cloud
   michael.d.mo...@nasa.gov

   Hydrogen fusion brightens my day.


   On 10/18/18, 1:07 AM, "iain MacDonnell"  wrote:



   On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS
   INTEGRA, INC.] wrote:

I’m seeing unexpected behavior in our Queens environment related to
Glance image visibility. Specifically users who, based on my
understanding of the visibility and ownership fields, should NOT be able
to see or view the image.

If I create a new image with openstack image create and specify –project
 and –private a non-admin user in a different tenant can see and
boot that image.

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


   Yep, something's not right there.

   Are you sure that the user that can see the image doesn't have the admin
   role (for the project in its keystone token) ?

   Did you verify that the image's owner is what you intended, and that the
   visibility really is "private" ?

~iain

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


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


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





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

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

2018-10-18 Thread Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]

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

Mike Moore, M.S.S.E.

Systems Engineer, Goddard Private Cloud
michael.d.mo...@nasa.gov

Hydrogen fusion brightens my day.

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

Yes. I verified it by creating a non-admin user in a different tenant. I 
created a new image, set to private with the project defined as our admin 
tenant.

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

Mike Moore, M.S.S.E.

Systems Engineer, Goddard Private Cloud
michael.d.mo...@nasa.gov

Hydrogen fusion brightens my day.

On 10/18/18, 1:07 AM, "iain MacDonnell"  wrote:

On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS 
INTEGRA, INC.] wrote:
> I’m seeing unexpected behavior in our Queens environment related to 
> Glance image visibility. Specifically users who, based on my 
> understanding of the visibility and ownership fields, should NOT be 
able 
> to see or view the image.
> 
> If I create a new image with openstack image create and specify 
–project 
>  and –private a non-admin user in a different tenant can see 
and 
> boot that image.
> 
> That seems to be the opposite of what should happen. Any ideas?

Yep, something's not right there.

Are you sure that the user that can see the image doesn't have the 
admin 
role (for the project in its keystone token) ?

Did you verify that the image's owner is what you intended, and that 
the 
visibility really is "private" ?

 ~iain

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

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

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

[Openstack-operators] [nova] Removing the CachingScheduler

2018-10-18 Thread Matt Riedemann


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

mgagne has been the most vocal CachingScheduler operator I know and he 
has tested out the "nova-manage placement heal_allocations" CLI, added 
in Rocky, and said it will work for migrating his deployment from the 
CachingScheduler to the FilterScheduler + Placement.


If you are using the CachingScheduler and have a problem with its 
removal, now is the time to speak up or forever hold your peace.


[1] https://review.openstack.org/#/c/611723/1

--

Thanks,

Matt

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

Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] [all] Naming the T release of OpenStack

2018-10-18 Thread Slawomir Kaplonski



> Wiadomość napisana przez Remo Mattei  w dniu 18.10.2018, o godz. 
> 19:08:
> 
> Michal, that will never work it’s 11 characters long

Shorter could be Openstack Trouble ;)
> 
> 
>  
> 
>> On Oct 18, 2018, at 09:43, Eric Fried  wrote:
>> 
>> Sorry, I'm opposed to this idea.
>> 
>> I admit I don't understand the political framework, nor have I read the
>> governing documents beyond [1], but that document makes it clear that
>> this is supposed to be a community-wide vote.  Is it really legal for
>> the TC (or whoever has merge rights on [2]) to merge a patch that gives
>> that same body the power to take the decision out of the hands of the
>> community? So it's really an oligarchy that gives its constituency the
>> illusion of democracy until something comes up that it feels like not
>> having a vote on? The fact that it's something relatively "unimportant"
>> (this time) is not a comfort.
>> 
>> Not that I think the TC would necessarily move forward with [2] in the
>> face of substantial opposition from non-TC "cores" or whatever.
>> 
>> I will vote enthusiastically for "Train". But a vote it should be.
>> 
>> -efried
>> 
>> [1] https://governance.openstack.org/tc/reference/release-naming.html
>> [2] https://review.openstack.org/#/c/611511/
>> 
>> On 10/18/2018 10:52 AM, arkady.kanev...@dell.com wrote:
>>> +1 for the poll.
>>> 
>>> Let’s follow well established process.
>>> 
>>> If we want to add Train as one of the options for the name I am OK with it.
>>> 
>>>  
>>> 
>>> *From:* Jonathan Mills 
>>> *Sent:* Thursday, October 18, 2018 10:49 AM
>>> *To:* openstack-s...@lists.openstack.org
>>> *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack
>>> 
>>>  
>>> 
>>> [EXTERNAL EMAIL]
>>> Please report any suspicious attachments, links, or requests for
>>> sensitive information.
>>> 
>>> +1 for just having a poll
>>> 
>>>  
>>> 
>>> On Thu, Oct 18, 2018 at 11:39 AM David Medberry >> > wrote:
>>> 
>>>I'm fine with Train but I'm also fine with just adding it to the
>>>list and voting on it. It will win.
>>> 
>>> 
>>> 
>>>Also, for those not familiar with the debian/ubuntu command "sl",
>>>now is the time to become so.
>>> 
>>> 
>>> 
>>>apt install sl
>>> 
>>>sl -Flea #ftw
>>> 
>>> 
>>> 
>>>On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds
>>>mailto:t...@bakeyournoodle.com>> wrote:
>>> 
>>>Hello all,
>>>As per [1] the nomination period for names for the T release
>>>have
>>>now closed (actually 3 days ago sorry).  The nominated names and any
>>>qualifying remarks can be seen at2].
>>> 
>>>Proposed Names
>>> * Tarryall
>>> * Teakettle
>>> * Teller
>>> * Telluride
>>> * Thomas
>>> * Thornton
>>> * Tiger
>>> * Tincup
>>> * Timnath
>>> * Timber
>>> * Tiny Town
>>> * Torreys
>>> * Trail
>>> * Trinidad
>>> * Treasure
>>> * Troublesome
>>> * Trussville
>>> * Turret
>>> * Tyrone
>>> 
>>>Proposed Names that do not meet the criteria
>>> * Train
>>> 
>>>However I'd like to suggest we skip the CIVS poll and select
>>>'Train' as
>>>the release name by TC resolution[3].  My think for this is
>>> 
>>> * It's fun and celebrates a humorous moment in our community
>>> * As a developer I've heard the T release called Train for quite
>>>   sometime, and was used often at the PTG[4].
>>> * As the *next* PTG is also in Colorado we can still choose a
>>>   geographic based name for U[5]
>>> * If train causes a problem for trademark reasons then we can
>>>always
>>>   run the poll
>>> 
>>>I'll leave[3] for marked -W for a week for discussion to happen
>>>before the
>>>TC can consider / vote on it.
>>> 
>>>Yours Tony.
>>> 
>>>[1]
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
>>>[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
>>>[3]
>>>
>>> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
>>>[4] https://twitter.com/vkmc/status/1040321043959754752
>>>[5]
>>>https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
>>>
>>> 
>>>___
>>>openstack-sigs mailing list
>>>openstack-s...@lists.openstack.org
>>>
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>>> 
>>>___
>>>openstack-sigs mailing list
>>>openstack-s...@lists.openstack.org
>>>
>>>

Re: [Openstack-operators] [OCTAVIA][QUEENS][KOLLA] - network/subnet not found.

2018-10-18 Thread Michael Johnson

Hi there.

I'm not sure what is happening there and I don't use kolla, so I need
to ask a few more questions.

Is that network ID being used for the VIP or the lb-mgmt-net?

Any chance you can provide a debug log paste from the API process for
this request?

Basically it is saying that network ID is invalid for the user making
the request.
This can happen if the user token being used doesn't have access to
that network, as an example.

It could also be a permissions issue with the service auth account
being used for the Octavia API, but this is unlikely.

Michael

On Thu, Oct 18, 2018 at 8:51 AM Gaël THEROND  wrote:
>
> Hi guys,
>
> I'm back to business with Octavia after a long time but I'm facing an issue 
> that seems a little bit tricky.
>
> When trying to create a LB using either APIs (cURL/postman) calls or 
> openstack-client the request finish with an error such as:
>
> `Network c0d40dfd-123e-4a3c-92de-eb7b57178dd3 not found. (HTTP 400)`
>
> If I put my client or the Octavia api in DEBUG mode, I found out neutron to 
> correctly sending back to him a RESP BODY with the requested network/subnet 
> in it.
>
> Here is the stacktrace that I get from both, Openstack client and the Octavia 
> API logs:
>
> ```
> POST call to 
> https://api-emea-west-az1.cloud.inkdrop.sh:9876/v2.0/lbaas/loadbalancers used 
> request id req-2f929192-4e60-491b-b65d-3a7bef43e978
> Request returned failure status: 400
> Network c0d40dfd-123e-4a3c-92de-eb7b57178dd3 not found. (HTTP 400) 
> (Request-ID: req-2f929192-4e60-491b-b65d-3a7bef43e978)
> Traceback (most recent call last):
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
>  line 29, in wrapper
> response = func(*args, **kwargs)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
>  line 92, in load_balancer_create
> response = self.create(url, **params)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/api/api.py",
>  line 164, in create
> ret = self._request(method, url, session=session, **params)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/api/api.py",
>  line 141, in _request
> return session.request(url, method, **kwargs)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/keystoneauth1/session.py",
>  line 869, in request
> raise exceptions.from_response(resp, method, url)
> keystoneauth1.exceptions.http.BadRequest: Bad Request (HTTP 400) (Request-ID: 
> req-2f929192-4e60-491b-b65d-3a7bef43e978)
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/cliff/app.py",
>  line 402, in run_subcommand
> result = cmd.run(parsed_args)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/command/command.py",
>  line 41, in run
> return super(Command, self).run(parsed_args)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/cliff/display.py",
>  line 116, in run
> column_names, data = self.take_action(parsed_args)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/osc/v2/load_balancer.py",
>  line 121, in take_action
> json=body)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
>  line 38, in wrapper
> request_id=e.request_id)
> octaviaclient.api.v2.octavia.OctaviaClientException: Network 
> c0d40dfd-123e-4a3c-92de-eb7b57178dd3 not found. (HTTP 400) (Request-ID: 
> req-2f929192-4e60-491b-b65d-3a7bef43e978)
> clean_up CreateLoadBalancer: Network c0d40dfd-123e-4a3c-92de-eb7b57178dd3 not 
> found. (HTTP 400) (Request-ID: req-2f929192-4e60-491b-b65d-3a7bef43e978)
> Traceback (most recent call last):
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
>  line 29, in wrapper
> response = func(*args, **kwargs)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
>  line 92, in load_balancer_create
> response = self.create(url, **params)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/api/api.py",
>  line 164, in create
> ret = self._request(method, url, session=session, **params)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/api/api.py",
>  line 141, in _request
> return session.request(url, method, **kwargs)
>   File 
> "/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/keystoneauth1/session.py",
>  line 869, in request
> raise exceptions.from_response(resp, method, url)
> keystoneauth1.exceptions.http.BadRequest: Bad Request (HTTP 400) (Request-ID: 
> req-2f929192-4e60-491b-b65d-3a7bef43e978)
>
>

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

2018-10-18 Thread Ignazio Cassano

Hello, sorry for late in my answer
the following is the content of my ocata repo file:

[centos-openstack-ocata]
name=CentOS-7 - OpenStack ocata
baseurl=http://mirror.centos.org/centos/7/cloud/$basearch/openstack-ocata/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Cloud
exclude=sip,PyQt4


Epel is not enable as suggested in documentation-
Regards
Ignazio

Il giorno gio 18 ott 2018 alle ore 10:24 Sylvain Bauza 
ha scritto:

>
>
> On Wed, Oct 17, 2018 at 4:46 PM Ignazio Cassano 
> wrote:
>
>> Hello, here the select you suggested:
>>
>> MariaDB [nova]> select * from shadow_services;
>> Empty set (0,00 sec)
>>
>> MariaDB [nova]> select * from shadow_compute_nodes;
>> Empty set (0,00 sec)
>>
>> As far as the upgrade tooling is concerned, we are using only yum update
>> on old compute nodes to have same packages installed on the new
>> compute-nodes
>>
>
>
> Well, to be honest, I was looking at some other bug for OSP
> https://bugzilla.redhat.com/show_bug.cgi?id=1636463 which is pretty
> identical so you're not alone :-)
> For some reason, yum update modifies something in the DB that I don't know
> yet. Which exact packages are you using ? RDO ones ?
>
> I marked the downstream bug as NOTABUG since I wasn't able to reproduce it
> and given I also provided a SQL query for fixing it, but maybe we should
> try to see which specific package has a problem...
>
> -Sylvain
>
>
> Procedure used
>> We have an openstack with 3 compute nodes : podto1-kvm01, podto1-kvm02,
>> podto1-kvm03
>> 1) install a new compute node (podto1-kvm04)
>> 2) On controller we discovered the new compute node: su -s /bin/sh -c
>> "nova-manage cell_v2 discover_hosts --verbose" nova
>> 3) Evacuate podto1-kvm01
>> 4) yum update on podto1-kvm01 and reboot it
>> 5) Evacuate podto1-kvm02
>> 6) yum update on podto1-kvm02 and reboot it
>> 7) Evacuate podto1-kvm03
>> 8) yum update podto1-kvm03 and reboot it
>>
>>
>>
>> Il giorno mer 17 ott 2018 alle ore 16:37 Matt Riedemann <
>> mriede...@gmail.com> ha scritto:
>>
>>> On 10/17/2018 9:13 AM, Ignazio Cassano wrote:
>>> > Hello Sylvain, here the output of some selects:
>>> > MariaDB [nova]> select host,hypervisor_hostname from compute_nodes;
>>> > +--+-+
>>> > | host | hypervisor_hostname |
>>> > +--+-+
>>> > | podto1-kvm01 | podto1-kvm01|
>>> > | podto1-kvm02 | podto1-kvm02|
>>> > | podto1-kvm03 | podto1-kvm03|
>>> > | podto1-kvm04 | podto1-kvm04|
>>> > | podto1-kvm05 | podto1-kvm05|
>>> > +--+-+
>>> >
>>> > MariaDB [nova]> select host from compute_nodes where
>>> host='podto1-kvm01'
>>> > and hypervisor_hostname='podto1-kvm01';
>>> > +--+
>>> > | host |
>>> > +--+
>>> > | podto1-kvm01 |
>>> > +--+
>>>
>>> Does your upgrade tooling run a db archive/purge at all? It's possible
>>> that the actual services table record was deleted via the os-services
>>> REST API for some reason, which would delete the compute_nodes table
>>> record, and then a restart of the nova-compute process would recreate
>>> the services and compute_nodes table records, but with a new compute
>>> node uuid and thus a new resource provider.
>>>
>>> Maybe query your shadow_services and shadow_compute_nodes tables for
>>> "podto1-kvm01" and see if a record existed at one point, was deleted and
>>> then archived to the shadow tables.
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Openstack-sigs] [all] Naming the T release of OpenStack

2018-10-18 Thread Eric Fried

Sorry, I'm opposed to this idea.

I admit I don't understand the political framework, nor have I read the
governing documents beyond [1], but that document makes it clear that
this is supposed to be a community-wide vote.  Is it really legal for
the TC (or whoever has merge rights on [2]) to merge a patch that gives
that same body the power to take the decision out of the hands of the
community? So it's really an oligarchy that gives its constituency the
illusion of democracy until something comes up that it feels like not
having a vote on? The fact that it's something relatively "unimportant"
(this time) is not a comfort.

Not that I think the TC would necessarily move forward with [2] in the
face of substantial opposition from non-TC "cores" or whatever.

I will vote enthusiastically for "Train". But a vote it should be.

-efried

[1] https://governance.openstack.org/tc/reference/release-naming.html
[2] https://review.openstack.org/#/c/611511/

On 10/18/2018 10:52 AM, arkady.kanev...@dell.com wrote:
> +1 for the poll.
> 
> Let’s follow well established process.
> 
> If we want to add Train as one of the options for the name I am OK with it.
> 
>  
> 
> *From:* Jonathan Mills 
> *Sent:* Thursday, October 18, 2018 10:49 AM
> *To:* openstack-s...@lists.openstack.org
> *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack
> 
>  
> 
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for
> sensitive information.
> 
> +1 for just having a poll
> 
>  
> 
> On Thu, Oct 18, 2018 at 11:39 AM David Medberry  > wrote:
> 
> I'm fine with Train but I'm also fine with just adding it to the
> list and voting on it. It will win.
> 
>  
> 
> Also, for those not familiar with the debian/ubuntu command "sl",
> now is the time to become so.
> 
>  
> 
> apt install sl
> 
> sl -Flea #ftw
> 
>  
> 
> On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds
> mailto:t...@bakeyournoodle.com>> wrote:
> 
> Hello all,
>     As per [1] the nomination period for names for the T release
> have
> now closed (actually 3 days ago sorry).  The nominated names and any
> qualifying remarks can be seen at2].
> 
> Proposed Names
>  * Tarryall
>  * Teakettle
>  * Teller
>  * Telluride
>  * Thomas
>  * Thornton
>  * Tiger
>  * Tincup
>  * Timnath
>  * Timber
>  * Tiny Town
>  * Torreys
>  * Trail
>  * Trinidad
>  * Treasure
>  * Troublesome
>  * Trussville
>  * Turret
>  * Tyrone
> 
> Proposed Names that do not meet the criteria
>  * Train
> 
> However I'd like to suggest we skip the CIVS poll and select
> 'Train' as
> the release name by TC resolution[3].  My think for this is
> 
>  * It's fun and celebrates a humorous moment in our community
>  * As a developer I've heard the T release called Train for quite
>    sometime, and was used often at the PTG[4].
>  * As the *next* PTG is also in Colorado we can still choose a
>    geographic based name for U[5]
>  * If train causes a problem for trademark reasons then we can
> always
>    run the poll
> 
> I'll leave[3] for marked -W for a week for discussion to happen
> before the
> TC can consider / vote on it.
> 
> Yours Tony.
> 
> [1]
> 
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
> [3]
> 
> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
> [4] https://twitter.com/vkmc/status/1040321043959754752
> [5]
> https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
> 
> 
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
> 
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
> 
> 
> 
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
> 

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

[Openstack-operators] [OCTAVIA][QUEENS][KOLLA] - network/subnet not found.

2018-10-18 Thread Gaël THEROND

Hi guys,

I'm back to business with Octavia after a long time but I'm facing an issue
that seems a little bit tricky.

When trying to create a LB using either APIs (cURL/postman) calls or
openstack-client the request finish with an error such as:

`Network c0d40dfd-123e-4a3c-92de-eb7b57178dd3 not found. (HTTP 400)`

If I put my client or the Octavia api in DEBUG mode, I found out neutron to
correctly sending back to him a RESP BODY with the requested network/subnet
in it.

Here is the stacktrace that I get from both, Openstack client and the
Octavia API logs:

```
POST call to
https://api-emea-west-az1.cloud.inkdrop.sh:9876/v2.0/lbaas/loadbalancers
used request id req-2f929192-4e60-491b-b65d-3a7bef43e978
Request returned failure status: 400
Network c0d40dfd-123e-4a3c-92de-eb7b57178dd3 not found. (HTTP 400)
(Request-ID: req-2f929192-4e60-491b-b65d-3a7bef43e978)
Traceback (most recent call last):
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
line 29, in wrapper
response = func(*args, **kwargs)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
line 92, in load_balancer_create
response = self.create(url, **params)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/api/api.py",
line 164, in create
ret = self._request(method, url, session=session, **params)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/api/api.py",
line 141, in _request
return session.request(url, method, **kwargs)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/keystoneauth1/session.py",
line 869, in request
raise exceptions.from_response(resp, method, url)
keystoneauth1.exceptions.http.BadRequest: Bad Request (HTTP 400)
(Request-ID: req-2f929192-4e60-491b-b65d-3a7bef43e978)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/cliff/app.py",
line 402, in run_subcommand
result = cmd.run(parsed_args)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/command/command.py",
line 41, in run
return super(Command, self).run(parsed_args)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/cliff/display.py",
line 116, in run
column_names, data = self.take_action(parsed_args)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/osc/v2/load_balancer.py",
line 121, in take_action
json=body)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
line 38, in wrapper
request_id=e.request_id)
octaviaclient.api.v2.octavia.OctaviaClientException: Network
c0d40dfd-123e-4a3c-92de-eb7b57178dd3 not found. (HTTP 400) (Request-ID:
req-2f929192-4e60-491b-b65d-3a7bef43e978)
clean_up CreateLoadBalancer: Network c0d40dfd-123e-4a3c-92de-eb7b57178dd3
not found. (HTTP 400) (Request-ID: req-2f929192-4e60-491b-b65d-3a7bef43e978)
Traceback (most recent call last):
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
line 29, in wrapper
response = func(*args, **kwargs)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/octaviaclient/api/v2/octavia.py",
line 92, in load_balancer_create
response = self.create(url, **params)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/api/api.py",
line 164, in create
ret = self._request(method, url, session=session, **params)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/api/api.py",
line 141, in _request
return session.request(url, method, **kwargs)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/keystoneauth1/session.py",
line 869, in request
raise exceptions.from_response(resp, method, url)
keystoneauth1.exceptions.http.BadRequest: Bad Request (HTTP 400)
(Request-ID: req-2f929192-4e60-491b-b65d-3a7bef43e978)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/shell.py",
line 135, in run
ret_val = super(OpenStackShell, self).run(argv)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/cliff/app.py",
line 281, in run
result = self.run_subcommand(remainder)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/shell.py",
line 175, in run_subcommand
ret_value = super(OpenStackShell, self).run_subcommand(argv)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/cliff/app.py",
line 402, in run_subcommand
result = cmd.run(parsed_args)
  File
"/home/flint/.virtualenvs/ic-emea-az1/lib/python3.4/site-packages/osc_lib/command/command.py",
line 41, in

Re: [Openstack-operators] [all] Naming the T release of OpenStack

2018-10-18 Thread iain MacDonnell




On 10/18/2018 08:31 AM, Anita Kuno wrote:

On 2018-10-18 2:35 a.m., Tony Breeds wrote:

...

However I'd like to suggest we skip the CIVS poll and select 'Train' as
the release name by TC resolution[3].  My think for this is

  * It's fun and celebrates a humorous moment in our community
  * As a developer I've heard the T release called Train for quite
    sometime, and was used often at the PTG[4].
  * As the *next* PTG is also in Colorado we can still choose a
    geographic based name for U[5]
  * If train causes a problem for trademark reasons then we can always
    run the poll

I'll leave[3] for marked -W for a week for discussion to happen before 
the TC can consider / vote on it.


I stand in opposition to any action that further undermines democracy.

I have avoided events in Denver lately for this reason.

If the support for Train is as universal as is portrayed, the poll with 
show us that.


I don't care what the name is. I do want to participate in the 
selection. The method of participating has heretofore been a poll. I 
have seen no convincing argument to abandon the use of a poll now.


I stand for what democracy there remains. I would like to participate in 
a poll.


+1

... and if you're not going to use the nominations, don't waste people's 
time asking for submissions.


I'm not super-fond of Train, since "release train" means something 
(else), at least in some contexts...


~iain

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

Re: [Openstack-operators] [all] Naming the T release of OpenStack

2018-10-18 Thread Zhipeng Huang

Just do a vote as usual, train is a great candidate :)

On Thu, Oct 18, 2018 at 11:44 PM Melvin Hillsman 
wrote:

> I agree with Anita and wonder why Train did not meet the criteria? If
> there is no way for Train to be an option outside of killing the voting,
> than for the sake of integrity of processes which I have heard quite a few
> people hold close to we should drop Train from the list. It is an
> unfortunate thing in my view because I am actually a "non-developer" who
> agreed during the feedback session that Train would be a great name but
> Anita is right on this one imho.
>
> On Thu, Oct 18, 2018 at 10:32 AM Anita Kuno  wrote:
>
>> On 2018-10-18 2:35 a.m., Tony Breeds wrote:
>> > Hello all,
>> >  As per [1] the nomination period for names for the T release have
>> > now closed (actually 3 days ago sorry).  The nominated names and any
>> > qualifying remarks can be seen at2].
>> >
>> > Proposed Names
>> >   * Tarryall
>> >   * Teakettle
>> >   * Teller
>> >   * Telluride
>> >   * Thomas
>> >   * Thornton
>> >   * Tiger
>> >   * Tincup
>> >   * Timnath
>> >   * Timber
>> >   * Tiny Town
>> >   * Torreys
>> >   * Trail
>> >   * Trinidad
>> >   * Treasure
>> >   * Troublesome
>> >   * Trussville
>> >   * Turret
>> >   * Tyrone
>> >
>> > Proposed Names that do not meet the criteria
>> >   * Train
>> >
>> > However I'd like to suggest we skip the CIVS poll and select 'Train' as
>> > the release name by TC resolution[3].  My think for this is
>> >
>> >   * It's fun and celebrates a humorous moment in our community
>> >   * As a developer I've heard the T release called Train for quite
>> > sometime, and was used often at the PTG[4].
>> >   * As the *next* PTG is also in Colorado we can still choose a
>> > geographic based name for U[5]
>> >   * If train causes a problem for trademark reasons then we can always
>> > run the poll
>> >
>> > I'll leave[3] for marked -W for a week for discussion to happen before
>> the
>> > TC can consider / vote on it.
>> >
>> > Yours Tony.
>> >
>> > [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
>> > [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
>> > [3]
>> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
>> > [4] https://twitter.com/vkmc/status/1040321043959754752
>> > [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
>>
>> I stand in opposition to any action that further undermines democracy.
>>
>> I have avoided events in Denver lately for this reason.
>>
>> If the support for Train is as universal as is portrayed, the poll with
>> show us that.
>>
>> I don't care what the name is. I do want to participate in the
>> selection. The method of participating has heretofore been a poll. I
>> have seen no convincing argument to abandon the use of a poll now.
>>
>> I stand for what democracy there remains. I would like to participate in
>> a poll.
>>
>> Thank you, Anita
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> --
> Kind regards,
>
> Melvin Hillsman
> mrhills...@gmail.com
> mobile: (832) 264-2646
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [all] Naming the T release of OpenStack

2018-10-18 Thread Melvin Hillsman

I agree with Anita and wonder why Train did not meet the criteria? If there
is no way for Train to be an option outside of killing the voting, than for
the sake of integrity of processes which I have heard quite a few people
hold close to we should drop Train from the list. It is an unfortunate
thing in my view because I am actually a "non-developer" who agreed during
the feedback session that Train would be a great name but Anita is right on
this one imho.

On Thu, Oct 18, 2018 at 10:32 AM Anita Kuno  wrote:

> On 2018-10-18 2:35 a.m., Tony Breeds wrote:
> > Hello all,
> >  As per [1] the nomination period for names for the T release have
> > now closed (actually 3 days ago sorry).  The nominated names and any
> > qualifying remarks can be seen at2].
> >
> > Proposed Names
> >   * Tarryall
> >   * Teakettle
> >   * Teller
> >   * Telluride
> >   * Thomas
> >   * Thornton
> >   * Tiger
> >   * Tincup
> >   * Timnath
> >   * Timber
> >   * Tiny Town
> >   * Torreys
> >   * Trail
> >   * Trinidad
> >   * Treasure
> >   * Troublesome
> >   * Trussville
> >   * Turret
> >   * Tyrone
> >
> > Proposed Names that do not meet the criteria
> >   * Train
> >
> > However I'd like to suggest we skip the CIVS poll and select 'Train' as
> > the release name by TC resolution[3].  My think for this is
> >
> >   * It's fun and celebrates a humorous moment in our community
> >   * As a developer I've heard the T release called Train for quite
> > sometime, and was used often at the PTG[4].
> >   * As the *next* PTG is also in Colorado we can still choose a
> > geographic based name for U[5]
> >   * If train causes a problem for trademark reasons then we can always
> > run the poll
> >
> > I'll leave[3] for marked -W for a week for discussion to happen before
> the
> > TC can consider / vote on it.
> >
> > Yours Tony.
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
> > [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
> > [3]
> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
> > [4] https://twitter.com/vkmc/status/1040321043959754752
> > [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
>
> I stand in opposition to any action that further undermines democracy.
>
> I have avoided events in Denver lately for this reason.
>
> If the support for Train is as universal as is portrayed, the poll with
> show us that.
>
> I don't care what the name is. I do want to participate in the
> selection. The method of participating has heretofore been a poll. I
> have seen no convincing argument to abandon the use of a poll now.
>
> I stand for what democracy there remains. I would like to participate in
> a poll.
>
> Thank you, Anita
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>


-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Openstack-sigs] [all] Naming the T release of OpenStack

2018-10-18 Thread David Medberry

and any talks I give in Denver (Forum, Ops, Main) will include "sl". It's
handy in a variety of ways.

On Thu, Oct 18, 2018 at 9:39 AM David Medberry 
wrote:

> I'm fine with Train but I'm also fine with just adding it to the list and
> voting on it. It will win.
>
> Also, for those not familiar with the debian/ubuntu command "sl", now is
> the time to become so.
>
> apt install sl
> sl -Flea #ftw
>
> On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds 
> wrote:
>
>> Hello all,
>> As per [1] the nomination period for names for the T release have
>> now closed (actually 3 days ago sorry).  The nominated names and any
>> qualifying remarks can be seen at2].
>>
>> Proposed Names
>>  * Tarryall
>>  * Teakettle
>>  * Teller
>>  * Telluride
>>  * Thomas
>>  * Thornton
>>  * Tiger
>>  * Tincup
>>  * Timnath
>>  * Timber
>>  * Tiny Town
>>  * Torreys
>>  * Trail
>>  * Trinidad
>>  * Treasure
>>  * Troublesome
>>  * Trussville
>>  * Turret
>>  * Tyrone
>>
>> Proposed Names that do not meet the criteria
>>  * Train
>>
>> However I'd like to suggest we skip the CIVS poll and select 'Train' as
>> the release name by TC resolution[3].  My think for this is
>>
>>  * It's fun and celebrates a humorous moment in our community
>>  * As a developer I've heard the T release called Train for quite
>>sometime, and was used often at the PTG[4].
>>  * As the *next* PTG is also in Colorado we can still choose a
>>geographic based name for U[5]
>>  * If train causes a problem for trademark reasons then we can always
>>run the poll
>>
>> I'll leave[3] for marked -W for a week for discussion to happen before the
>> TC can consider / vote on it.
>>
>> Yours Tony.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
>> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
>> [3]
>> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
>> [4] https://twitter.com/vkmc/status/1040321043959754752
>> [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
>> ___
>> openstack-sigs mailing list
>> openstack-s...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Openstack-sigs] [all] Naming the T release of OpenStack

2018-10-18 Thread David Medberry

I'm fine with Train but I'm also fine with just adding it to the list and
voting on it. It will win.

Also, for those not familiar with the debian/ubuntu command "sl", now is
the time to become so.

apt install sl
sl -Flea #ftw

On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds 
wrote:

> Hello all,
> As per [1] the nomination period for names for the T release have
> now closed (actually 3 days ago sorry).  The nominated names and any
> qualifying remarks can be seen at2].
>
> Proposed Names
>  * Tarryall
>  * Teakettle
>  * Teller
>  * Telluride
>  * Thomas
>  * Thornton
>  * Tiger
>  * Tincup
>  * Timnath
>  * Timber
>  * Tiny Town
>  * Torreys
>  * Trail
>  * Trinidad
>  * Treasure
>  * Troublesome
>  * Trussville
>  * Turret
>  * Tyrone
>
> Proposed Names that do not meet the criteria
>  * Train
>
> However I'd like to suggest we skip the CIVS poll and select 'Train' as
> the release name by TC resolution[3].  My think for this is
>
>  * It's fun and celebrates a humorous moment in our community
>  * As a developer I've heard the T release called Train for quite
>sometime, and was used often at the PTG[4].
>  * As the *next* PTG is also in Colorado we can still choose a
>geographic based name for U[5]
>  * If train causes a problem for trademark reasons then we can always
>run the poll
>
> I'll leave[3] for marked -W for a week for discussion to happen before the
> TC can consider / vote on it.
>
> Yours Tony.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
> [3]
> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
> [4] https://twitter.com/vkmc/status/1040321043959754752
> [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [all] Naming the T release of OpenStack

2018-10-18 Thread Anita Kuno


On 2018-10-18 2:35 a.m., Tony Breeds wrote:

Hello all,
 As per [1] the nomination period for names for the T release have
now closed (actually 3 days ago sorry).  The nominated names and any
qualifying remarks can be seen at2].

Proposed Names
  * Tarryall
  * Teakettle
  * Teller
  * Telluride
  * Thomas
  * Thornton
  * Tiger
  * Tincup
  * Timnath
  * Timber
  * Tiny Town
  * Torreys
  * Trail
  * Trinidad
  * Treasure
  * Troublesome
  * Trussville
  * Turret
  * Tyrone

Proposed Names that do not meet the criteria
  * Train

However I'd like to suggest we skip the CIVS poll and select 'Train' as
the release name by TC resolution[3].  My think for this is

  * It's fun and celebrates a humorous moment in our community
  * As a developer I've heard the T release called Train for quite
sometime, and was used often at the PTG[4].
  * As the *next* PTG is also in Colorado we can still choose a
geographic based name for U[5]
  * If train causes a problem for trademark reasons then we can always
run the poll

I'll leave[3] for marked -W for a week for discussion to happen before the
TC can consider / vote on it.

Yours Tony.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
[3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
[4] https://twitter.com/vkmc/status/1040321043959754752
[5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z


I stand in opposition to any action that further undermines democracy.

I have avoided events in Denver lately for this reason.

If the support for Train is as universal as is portrayed, the poll with 
show us that.


I don't care what the name is. I do want to participate in the 
selection. The method of participating has heretofore been a poll. I 
have seen no convincing argument to abandon the use of a poll now.


I stand for what democracy there remains. I would like to participate in 
a poll.


Thank you, Anita

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

Re: [Openstack-operators] [Openstack-sigs] [openstack-dev] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps

2018-10-18 Thread Sean McGinnis

On Wed, Oct 17, 2018 at 10:41:36AM -0500, Matt Riedemann wrote:
> On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote:
> > 
> > As you may know, unfortunately, Horizon doesn't support all features
> > provided by APIs. That's why we created feature gaps list [1].
> > 
> > I'd got a lot of great conversations with projects teams during the PTG
> > and we tried to figure out what should be done prioritize these tasks.
> > It's really helpful for Horizon to get feedback from other teams to
> > understand what features should be implemented next.
> > 
> > While I'm filling launchpad with new bugs and blueprints for [1], it
> > would be good to review this list again and find some volunteers to
> > decrease feature gaps.
> > 
> > [1] https://etherpad.openstack.org/p/horizon-feature-gap
> > 
> > Thanks everybody for any of your contributions to Horizon.
> 
> +openstack-sigs
> +openstack-operators
> 
> I've left some notes for nova. This looks very similar to the compute API
> OSC gap analysis I did [1]. Unfortunately it's hard to prioritize what to
> really work on without some user/operator feedback - maybe we can get the
> user work group involved in trying to help prioritize what people really
> want that is missing from horizon, at least for compute?
> 
> [1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
> 
> -- 
> 
> Thanks,
> 
> Matt

I also have a cinderclient OSC gap analysis I've started working on. It might
be useful to add a Horizon column to this list too.

https://ethercalc.openstack.org/cinderclient-osc-gap

Sean

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

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

2018-10-18 Thread Sylvain Bauza

On Wed, Oct 17, 2018 at 4:46 PM Ignazio Cassano 
wrote:

> Hello, here the select you suggested:
>
> MariaDB [nova]> select * from shadow_services;
> Empty set (0,00 sec)
>
> MariaDB [nova]> select * from shadow_compute_nodes;
> Empty set (0,00 sec)
>
> As far as the upgrade tooling is concerned, we are using only yum update
> on old compute nodes to have same packages installed on the new
> compute-nodes
>


Well, to be honest, I was looking at some other bug for OSP
https://bugzilla.redhat.com/show_bug.cgi?id=1636463 which is pretty
identical so you're not alone :-)
For some reason, yum update modifies something in the DB that I don't know
yet. Which exact packages are you using ? RDO ones ?

I marked the downstream bug as NOTABUG since I wasn't able to reproduce it
and given I also provided a SQL query for fixing it, but maybe we should
try to see which specific package has a problem...

-Sylvain


Procedure used
> We have an openstack with 3 compute nodes : podto1-kvm01, podto1-kvm02,
> podto1-kvm03
> 1) install a new compute node (podto1-kvm04)
> 2) On controller we discovered the new compute node: su -s /bin/sh -c
> "nova-manage cell_v2 discover_hosts --verbose" nova
> 3) Evacuate podto1-kvm01
> 4) yum update on podto1-kvm01 and reboot it
> 5) Evacuate podto1-kvm02
> 6) yum update on podto1-kvm02 and reboot it
> 7) Evacuate podto1-kvm03
> 8) yum update podto1-kvm03 and reboot it
>
>
>
> Il giorno mer 17 ott 2018 alle ore 16:37 Matt Riedemann <
> mriede...@gmail.com> ha scritto:
>
>> On 10/17/2018 9:13 AM, Ignazio Cassano wrote:
>> > Hello Sylvain, here the output of some selects:
>> > MariaDB [nova]> select host,hypervisor_hostname from compute_nodes;
>> > +--+-+
>> > | host | hypervisor_hostname |
>> > +--+-+
>> > | podto1-kvm01 | podto1-kvm01|
>> > | podto1-kvm02 | podto1-kvm02|
>> > | podto1-kvm03 | podto1-kvm03|
>> > | podto1-kvm04 | podto1-kvm04|
>> > | podto1-kvm05 | podto1-kvm05|
>> > +--+-+
>> >
>> > MariaDB [nova]> select host from compute_nodes where
>> host='podto1-kvm01'
>> > and hypervisor_hostname='podto1-kvm01';
>> > +--+
>> > | host |
>> > +--+
>> > | podto1-kvm01 |
>> > +--+
>>
>> Does your upgrade tooling run a db archive/purge at all? It's possible
>> that the actual services table record was deleted via the os-services
>> REST API for some reason, which would delete the compute_nodes table
>> record, and then a restart of the nova-compute process would recreate
>> the services and compute_nodes table records, but with a new compute
>> node uuid and thus a new resource provider.
>>
>> Maybe query your shadow_services and shadow_compute_nodes tables for
>> "podto1-kvm01" and see if a record existed at one point, was deleted and
>> then archived to the shadow tables.
>>
>> --
>>
>> Thanks,
>>
>> Matt
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [all] Naming the T release of OpenStack

2018-10-18 Thread Tony Breeds

Hello all,
As per [1] the nomination period for names for the T release have
now closed (actually 3 days ago sorry).  The nominated names and any
qualifying remarks can be seen at2].

Proposed Names
 * Tarryall
 * Teakettle
 * Teller
 * Telluride
 * Thomas
 * Thornton
 * Tiger
 * Tincup
 * Timnath
 * Timber
 * Tiny Town
 * Torreys
 * Trail
 * Trinidad
 * Treasure
 * Troublesome
 * Trussville
 * Turret
 * Tyrone

Proposed Names that do not meet the criteria
 * Train

However I'd like to suggest we skip the CIVS poll and select 'Train' as
the release name by TC resolution[3].  My think for this is 

 * It's fun and celebrates a humorous moment in our community
 * As a developer I've heard the T release called Train for quite
   sometime, and was used often at the PTG[4].
 * As the *next* PTG is also in Colorado we can still choose a
   geographic based name for U[5]
 * If train causes a problem for trademark reasons then we can always
   run the poll

I'll leave[3] for marked -W for a week for discussion to happen before the
TC can consider / vote on it.

Yours Tony.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
[3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
[4] https://twitter.com/vkmc/status/1040321043959754752
[5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z


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

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

[Openstack-operators] [nova] Removing the CachingScheduler

Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] [all] Naming the T release of OpenStack

Re: [Openstack-operators] [OCTAVIA][QUEENS][KOLLA] - network/subnet not found.

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

Re: [Openstack-operators] [Openstack-sigs] [all] Naming the T release of OpenStack

[Openstack-operators] [OCTAVIA][QUEENS][KOLLA] - network/subnet not found.

Re: [Openstack-operators] [all] Naming the T release of OpenStack

Re: [Openstack-operators] [all] Naming the T release of OpenStack

Re: [Openstack-operators] [all] Naming the T release of OpenStack

Re: [Openstack-operators] [Openstack-sigs] [all] Naming the T release of OpenStack

Re: [Openstack-operators] [Openstack-sigs] [all] Naming the T release of OpenStack

Re: [Openstack-operators] [all] Naming the T release of OpenStack

Re: [Openstack-operators] [Openstack-sigs] [openstack-dev] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps

Re: [Openstack-operators] nova_api resource_providers table issues on ocata

[Openstack-operators] [all] Naming the T release of OpenStack

21 matches

Site Navigation

Mail list logo

Footer information