[openstack-dev] New comer to Openstack.

[akula nagaraj reddy]

Hi All,

Please let someone give how to start the things. I have moderate experience
in Python .



*Thanks and Regards*

* Nagaraj R*
+919538750652
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Nova not powering on baremetal instances, ironic

[Ahmed Mostafa]

Hello all,

I have tried to use ironic in stand alone mode and i tried to integerate it
with nova

When i use it in stand alone mode, i craate a neutron port of vnic_type
baremetal and i assign it to the ironic node using extra/vif_port_id, i am
able to provision the node, but not able to get connectivity due to the
fact that the port always stays DOWN in neutron no matter what i do

When i tried to integerate nova compute, nova does not create the port and
therfore does not power on the node

Any idea on how to solve his ?

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

Re: [Openstack] [OpenStack] [Keystone] Performance difference between ferret and uuid tokens

[Alexandr Porunov]

Thank you very much for the explanation and for the articles. I will use
Newton release of Keystone and Swift. Thanks a lot

Best regards,
Alexandr

On Sat, Dec 10, 2016 at 11:13 PM, Steve Martinelli 
wrote:

> Re-sending Matt's reply since he is not subscribed to this mailing list
> and it bounced back.
>
> ---
>
> Matt Fischer wrote:
>
> Alexandr,
>
> I would not use Fernet without caching, but that said I strongly recommend
> against UUID tokens for any reason. Make sure you setup caching on the
> swift side & the keystone side. You could consider than an L1 and L2 cache
> where from Swift's POV it's authtoken cache is L1 and keystone's cache is
> L2. If you do that I believe the performance will be acceptable.
>
> The slowness comes when Keystone has to attempt to decrypt the uncached
> tokens.
>
> Also if you're looking to squeeze out the last bit of performance from
> your keystone, using the deprecated (and not tested in the gate)
> Python-MySQL driver instead of pymsql is about 6% faster. That carries
> risks as it's untested and becoming less widely used. We switched to
> pymysql as has openstack-ansible and several other deployments.
>
> On Sat, Dec 10, 2016 at 3:23 PM, Steve Martinelli 
> wrote:
>
>> On Sat, Dec 10, 2016 at 10:59 AM, Alexandr Porunov <
>> alexandr.poru...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I read a blog about performance comparison between fernet and uuid
>>> tokens. They said that fernet tokens is 30% faster for creation but 400%
>>> slower for validation. Is it true?
>>>
>>>
>> I assume you are reading Dolph's blog post [1], that data is based off of
>> the kilo branch, we've made some improvements to performance since then, he
>> should probably do a follow up post for how the same performance tests run
>> on Newton ;)
>>
>> Token validation can be improved using caching, which we worked on in
>> Liberty, Mitaka and Newton (the latest Mitaka release (9.2.0) includes a
>> critical performance fix, it was not backported to Liberty). Revocation
>> events are still an issue for performance, but we've been addressing that
>> in Ocata. I don't think we'll be able to backport the fixes for poor
>> revocation performance though, unfortunately it goes against the backport
>> policy.
>>
>>
>> FWIW, Matt Fischer has 4 blog posts about using fernet tokens in
>> production [2], they are very detailed and performance oriented. I really
>> recommend reading them, it's great stuff.
>>
>>
>> [1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
>> [2] https://www.mattfischer.com/blog/?tag=fernet
>>
>>
>> stevemar
>>
>>
>>
>>> I want to use Keystone for Swift. I will have many requests with the
>>> same tokens so I need faster validation than faster creation. I would use
>>> uuid tokens but fernet tokens give us very good pros (we don't need to use
>>> a database). So, I decided to cache all fernet tokens on the Swift Proxy
>>> side for 30 minutes. Will the performance be the same for checking tokens
>>> in a cache or fernet tokens will still be 400% slower?
>>>
>>> Sincerely,
>>> Alexandr
>>>
>>
>>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [OpenStack] [Keystone] Performance difference between ferret and uuid tokens

[Steve Martinelli]

On Sat, Dec 10, 2016 at 10:59 AM, Alexandr Porunov <
alexandr.poru...@gmail.com> wrote:

> Hello,
>
> I read a blog about performance comparison between fernet and uuid tokens.
> They said that fernet tokens is 30% faster for creation but 400% slower for
> validation. Is it true?
>
>
I assume you are reading Dolph's blog post [1], that data is based off of
the kilo branch, we've made some improvements to performance since then, he
should probably do a follow up post for how the same performance tests run
on Newton ;)

Token validation can be improved using caching, which we worked on in
Liberty, Mitaka and Newton (the latest Mitaka release (9.2.0) includes a
critical performance fix, it was not backported to Liberty). Revocation
events are still an issue for performance, but we've been addressing that
in Ocata. I don't think we'll be able to backport the fixes for poor
revocation performance though, unfortunately it goes against the backport
policy.


FWIW, Matt Fischer has 4 blog posts about using fernet tokens in production
[2], they are very detailed and performance oriented. I really recommend
reading them, it's great stuff.


[1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/
[2] https://www.mattfischer.com/blog/?tag=fernet


stevemar



> I want to use Keystone for Swift. I will have many requests with the same
> tokens so I need faster validation than faster creation. I would use uuid
> tokens but fernet tokens give us very good pros (we don't need to use a
> database). So, I decided to cache all fernet tokens on the Swift Proxy side
> for 30 minutes. Will the performance be the same for checking tokens in a
> cache or fernet tokens will still be 400% slower?
>
> Sincerely,
> Alexandr
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [glance] priorities for the coming week (12/09-12/15)

[Andrey Pavlov]

Hello,

Can you also review this - https://review.openstack.org/#/c/401277/
for bug - https://bugs.launchpad.net/glance-store/+bug/1644177

And please consider backport to Newton.

This bug is very annoying for deployments with several controllers and
glance over cinder...

On Fri, Dec 9, 2016 at 3:14 PM, Brian Rosmaita 
wrote:

> As discussed at the Glance weekly meeting yesterday, the priorities for
> 12/1 through 12/8, unfortunately look very similar to last week's
> priorities.  Some core reviewers need to step up.  The priorities are:
>
> Highest priority
> 
>
> (1) database strategy for rolling upgrades:
> https://review.openstack.org/#/c/331740/
> This one has a video to enhance your reviewing pleasure and demonstrate
> that the approach described actually is workable:
> https://www.youtube.com/watch?v=Z4iwJRlPqOw
>
> (2) glance expand/contract migrations with alembic:
> https://review.openstack.org/#/c/374278/
> We need another +2 on this one, preferably from a non-Rackspace person.
>
> (3) community images spec update:
> https://review.openstack.org/#/c/396919/
> New to the list.  The latest patch includes the migration strategy for
> which Erno said indicated on the patch he'd change his -2 to a +2, so
> don't let the -2 on the patch stop you from reviewing it.
>
> The above three specs need to be reviewed as soon as possible.  We are
> blocking Alex and Hemanth, because the Ocata database migration will
> handle the community images changes.
>
>
> Really high priority
> 
> (would be highest if the specs were already approved)
>
> (4) Patch to fix a glance_store regression:
> https://review.openstack.org/#/c/387719/
> and patch to prevent a related backend misconfiguration:
> https://review.openstack.org/#/c/388944/
>
> (5) Patch to enable better request-id tracking:
> https://review.openstack.org/#/c/352892/
> This will be nice for operators, let's get it reviewed and merged!
>
> (6) Request for some insights and opinions for bug
> https://bugs.launchpad.net/glance/+bug/1585917
>
>
> Please take a look
> ==
>
> (7) glanceclient problem: https://review.openstack.org/#/c/319960/
>
> thanks,
> brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind Regards,
Andrey Pavlov.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] Can't access instance - no ethernet interface

[Turbo Fredriksson]

On 9 Dec 2016, at 13:56, Turbo Fredriksson  wrote:

> I’m pretty sure it’s something simple, but I can’t seem to figure out what.

After fixing some issues with Cinder not being able to create a bootable volume,
I noticed that there is no ethernet interface!


[8.642245] systemd[1]: Started Initial cloud-init job 
(pre-networking).
[8.645378] systemd[1]: Reached target Network (Pre).
[8.647088] systemd[1]: Starting Raise network interfaces...
[8.770345] systemd[1]: Reloading.
[9.162225] dhclient[307]: Internet Systems Consortium DHCP Client 
4.3.5b1
[9.164458] ifup[266]: Internet Systems Consortium DHCP Client 
4.3.5b1
[9.166557] ifup[266]: Copyright 2004-2016 Internet Systems 
Consortium.
[9.168885] ifup[266]: All rights reserved.
[9.170673] ifup[266]: For info, please visit 
https://www.isc.org/software/dhcp/
[9.172625] dhclient[307]: Copyright 2004-2016 Internet Systems 
Consortium.
[9.175346] dhclient[307]: All rights reserved.
[9.177583] dhclient[307]: For info, please visit 
https://www.isc.org/software/dhcp/
[9.180276] dhclient[307]: 
[9.429158] ifup[266]: Cannot find device "eth0"
[9.444610] dhclient[307]: Failed to get interface index: No such 
device
[9.446616] ifup[266]: Failed to get interface index: No such device
[9.448290] ifup[266]: If you think you have received this message 
due to a bug rather
[9.450339] ifup[266]: than a configuration issue please read the 
section on submitting
[9.452388] ifup[266]: bugs on either our web page at www.isc.org or 
in the README file
[9.454261] ifup[266]: before submitting a bug.  These pages explain 
the proper
[9.456491] ifup[266]: process and the information we find helpful 
for debugging..
[9.458293] ifup[266]: exiting.
[9.459521] dhclient[307]: 
[9.460977] dhclient[307]: If you think you have received this 
message due to a bug rather
[9.463294] dhclient[307]: than a configuration issue please read 
the section on submitting
[9.465634] ifup[266]: Failed to bring up eth0.
[9.466846] dhclient[307]: bugs on either our web page at 
www.isc.org or in the README file
[9.468607] dhclient[307]: before submitting a bug.  These pages 
explain the proper
[9.469907] dhclient[307]: process and the information we find 
helpful for debugging..
[9.471590] dhclient[307]: 
[9.472475] dhclient[307]: exiting.


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron] trunk api performance and scale measurments

[Armando M.]

On 8 December 2016 at 20:55, Armando M.  wrote:

>
>
> On 5 December 2016 at 07:59, Bence Romsics 
> wrote:
>
>> Hi,
>>
>> I measured how the new trunk API scales with lots of subports. You can
>> find the results here:
>>
>> https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling
>>
>> Hope you find it useful. There are several open ends, let me know if
>> you're interested in following up some of them.
>>
>
> I looked into [1] a little bit as it bothered me :)
>
> Here's my findings:
>
>
>- openstack port list is slower than neutron port-list as it looks
>like the command goes to Nova first [2], which is where the overhead comes
>from.
>- when you have subports the port-list response gets bigger because of
>the bigger response due to the trunk-details extension.
>- However, the bulk of the time is spent in [3], when building the
>payload for a port involved as a parent port. In no other case you will see
>the overhead as in no other case the loop over subports is executed.
>
> The hook should be optimized!
>

Follow up: Kevin and I put together a couple of patches [1,2] to fix and
validate how to speed up the lookup. We'll dig into why sqlalchemy is
acting differently when listing ports with or without filters, but this
should do for now.

Cheers,
Armando

[1] https://review.openstack.org/#/c/409267/
[2] https://review.openstack.org/#/c/408983/


> [1] https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performanc
> e_and_Scaling#surprise_effect_on_filtered_port_listings
> [2] http://paste.openstack.org/show/591882/
> [3] https://github.com/openstack/neutron/blob/master/
> neutron/services/trunk/plugin.py#L42
>
>
>> Cheers,
>> Bence Romsics
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] Any serious stability and performance issues on RBD as ephemeral storage ?

[Vahric Muhtaryan]

Thanks Mike , 
Thanks for sharing 
VM

From:  Mike Smith 
Date:  Saturday, 10 December 2016 at 08:22
To:  Vahric Muhtaryan 
Cc:  David Medberry ,
"openstack-operators@lists.openstack.org"
, "m...@mattjarvis.org.uk"

Subject:  Re: [Openstack-operators] Any serious stability and performance
issues on RBD as ephemeral storage ?

Vahric - 

We use Ceph for nova ephemeral as well on thousands of VMs and we love it.
Fast provisioning of VMs, solid, reliable and flexible.   Works great with
live-migration.  The only time we ever have a problem is an OSD is allowed
to get too full.  Never let that happen!

Mike Smith
Lead Cloud Systems Architect
Overstock.com 



> On Dec 8, 2016, at 10:36 AM, Matt Jarvis  wrote:
> 
> I'd say using Ceph for ephemeral disks is the most common deployment pattern,
> at DataCentred we've been using it for years. It's rock solid and has been for
> several releases. There were some edge case issues around resizing and
> snapshotting, but I think that's all been fixed in the last couple of
> iterations.
> 
> On Thu, Dec 8, 2016 at 4:58 PM, David Medberry  wrote:
>> We've been using it and recommending it for years. It solves many many
>> problems with a running cloud and there have been very few issues. Pay close
>> attention when upgrading versions of CEPH and do things in the right order
>> and you will be fine!
>> 
>> On Wed, Dec 7, 2016 at 7:51 AM, Vahric Muhtaryan  wrote:
>>> Hello All, 
>>> 
>>> I would like to use ephemeral disks with ceph instead of on nova compute
>>> node. I saw that there is an option to configure it but find many different
>>> bugs and reports for its not working , not stable , no success at the
>>> instance creation time.
>>> Anybody In this list use ceph as an ephemeral storage without any problem ?
>>> Could you pls share your experiences pls ?
>>> 
>>> Regards
>>> VM
>>> 
>>> ___
>>> 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




CONFIDENTIALITY NOTICE: This message is intended only for the use and review
of the individual or entity to which it is addressed and may contain
information that is privileged and confidential. If the reader of this
message is not the intended recipient, or the employee or agent responsible
for delivering the message solely to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify sender immediately by telephone or
return email. Thank you.


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

[Openstack] [OpenStack] [Keystone] Performance difference between ferret and uuid tokens

[Alexandr Porunov]

Hello,

I read a blog about performance comparison between fernet and uuid tokens.
They said that fernet tokens is 30% faster for creation but 400% slower for
validation. Is it true?

I want to use Keystone for Swift. I will have many requests with the same
tokens so I need faster validation than faster creation. I would use uuid
tokens but fernet tokens give us very good pros (we don't need to use a
database). So, I decided to cache all fernet tokens on the Swift Proxy side
for 30 minutes. Will the performance be the same for checking tokens in a
cache or fernet tokens will still be 400% slower?

Sincerely,
Alexandr
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Malformed request URL doesn't match Context's project_id

[Jun Hu]

Hi John ,

you're right, thank you.

--

Margin Hu
Love Open Source Software.
Mobile: (86) 186-8035-6499
email : jhu_...@outlook.com
github: http://github.com/todaygood
-

On 12/10/2016 03:08 PM, John Petrini wrote:
It looks like when you request the token you are not providing tenantName so 
you're not generating a token for authenticating to tenant/project you want to 
authenticate to. i.e. e5ec75ca491049b2b3d6758269aad07c


___

John Petrini

On Sat, Dec 10, 2016 at 7:43 AM, Jun Hu 
> wrote:

Hi Guys:

My openstack version is Mitaka.  I want to use curl to call openstack API , but 
I met a issue. Can you help me ?

[root@ospp9-ctrl1 site-packages(keystone_demo)]# source ~/keystonerc_admin

[root@ospp9-ctrl1 site-packages(keystone_admin)]# curl -s -X POST 
$OS_AUTH_URL/tokens   -H "Content-Type: application/json" -d '{"auth": 
{"tenantName": "", "passwordCredentials": {"username": "'"$OS_USERNAME"'", 
"password": "'"$OS_PASSWORD"'"}}}'  | python -m json.tool
{
"access": {
"metadata": {
"is_admin": 0,
"roles": []
},
"serviceCatalog": [],
"token": {
"audit_ids": [
"RJrDyNfIShyKTmXu5IWZUw"
],
"expires": "2016-12-10T13:12:15Z",
"id": "80b3d146c5614c149ccf983b21d93055",
"issued_at": "2016-12-10T12:12:15.171884Z"
},
"user": {
"id": "ae11a07ef07e47bba4a91d1c3516ac01",
"name": "admin",
"roles": [],
"roles_links": [],
"username": "admin"
}
}
}
[root@ospp9-ctrl1 site-packages(keystone_admin)]# export 
OS_TOKEN=80b3d146c5614c149ccf983b21d93055
[root@ospp9-ctrl1 site-packages(keystone_admin)]# export 
OS_PROJECT_ID=e5ec75ca491049b2b3d6758269aad07c
[root@ospp9-ctrl1 site-packages(keystone_admin)]# curl -s -H 
"X-Auth-Token:$OS_TOKEN" 
http://192.168.122.64:8774/v2/e5ec75ca491049b2b3d6758269aad07c/flavors  | 
python -m json.tool
{
"badRequest": {
"code": 400,
"message": "Malformed request URL: URL's project_id 
'e5ec75ca491049b2b3d6758269aad07c' doesn't match Context's project_id 'None'"
}
}

[root@ospp9-ctrl1 site-packages(keystone_admin)]# openstack catalog show nova
+---+---+
| Field | Value 
|
+---+---+
| endpoints | RegionOne 
|
|   |   publicURL: 
http://192.168.122.64:8774/v2/e5ec75ca491049b2b3d6758269aad07c   |
|   |   internalURL: 
http://192.168.122.64:8774/v2/e5ec75ca491049b2b3d6758269aad07c |
|   |   adminURL: 
http://192.168.122.64:8774/v2/e5ec75ca491049b2b3d6758269aad07c|
|   |   
|
| name  | nova  
|
| type  | compute   
|
+---+---+

1. After I deep into the code, and have a question : How to get/set the 
context.project_id?


[root@ospp9-ctrl1 site-packages(keystone_admin)]# vim 
nova/api/openstack/wsgi.py +721
```python
   project_id = action_args.pop("project_id", None)
context = request.environ.get('nova.context')
if (context and project_id and (project_id != context.project_id)):
msg = _("Malformed request URL: URL's project_id '%(project_id)s'"
" doesn't match Context's project_id"
" '%(context_project_id)s'") % \
{'project_id': project_id,
 'context_project_id': context.project_id}
return Fault(webob.exc.HTTPBadRequest(explanation=msg))
```

2. Why  got empty SeviceCatalog"serviceCatalog": []" but  it is not in 
official docs

http://developer.openstack.org/api-guide/quick-start/api-quick-start.html#openstack-api-quick-guide


--

Margin Hu
Love Open Source Software.
Mobile: (86) 186-8035-6499
email : jhu_...@outlook.com
github: http://github.com/todaygood
 ---

___ Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : 
openstack@lists.openstack.org Unsubscribe 
: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Malformed request URL doesn't match Context's project_id

[John Petrini]

It looks like when you request the token you are not providing tenantName
so you're not generating a token for authenticating to tenant/project you
want to authenticate to. i.e. e5ec75ca491049b2b3d6758269aad07c

___

John Petrini

On Sat, Dec 10, 2016 at 7:43 AM, Jun Hu  wrote:

> Hi Guys:
>
> My openstack version is Mitaka.  I want to use curl to call openstack API
> , but I met a issue. Can you help me ?
>
> [root@ospp9-ctrl1 site-packages(keystone_demo)]# source ~/keystonerc_admin
>
> [root@ospp9-ctrl1 site-packages(keystone_admin)]# curl -s -X POST
> $OS_AUTH_URL/tokens   -H "Content-Type: application/json" -d '{"auth":
> {"tenantName": "", "passwordCredentials": {"username": "'"$OS_USERNAME"'",
> "password": "'"$OS_PASSWORD"'"}}}'  | python -m json.tool
> {
> "access": {
> "metadata": {
> "is_admin": 0,
> "roles": []
> },
> "serviceCatalog": [],
> "token": {
> "audit_ids": [
> "RJrDyNfIShyKTmXu5IWZUw"
> ],
> "expires": "2016-12-10T13:12:15Z",
> "id": "80b3d146c5614c149ccf983b21d93055",
> "issued_at": "2016-12-10T12:12:15.171884Z"
> },
> "user": {
> "id": "ae11a07ef07e47bba4a91d1c3516ac01",
> "name": "admin",
> "roles": [],
> "roles_links": [],
> "username": "admin"
> }
> }
> }
> [root@ospp9-ctrl1 site-packages(keystone_admin)]# export OS_TOKEN=
> 80b3d146c5614c149ccf983b21d93055
> [root@ospp9-ctrl1 site-packages(keystone_admin)]# export OS_PROJECT_ID=
> e5ec75ca491049b2b3d6758269aad07c
> [root@ospp9-ctrl1 site-packages(keystone_admin)]# curl -s -H
> "X-Auth-Token:$OS_TOKEN" http://192.168.122.64:8774/v2/
> e5ec75ca491049b2b3d6758269aad07c/flavors  | python -m json.tool
> {
> "badRequest": {
> "code": 400,
> "message": "Malformed request URL: URL's project_id '
> e5ec75ca491049b2b3d6758269aad07c' doesn't match Context's project_id
> 'None'"
> }
> }
>
> [root@ospp9-ctrl1 site-packages(keystone_admin)]# openstack catalog show
> nova
> +---+---
> +
> | Field | Value
> |
> +---+---
> +
> | endpoints | RegionOne
> |
> |   |   publicURL: http://192.168.122.64:8774/v2/
> e5ec75ca491049b2b3d6758269aad07c   |
> |   |   internalURL: http://192.168.122.64:8774/v2/
> e5ec75ca491049b2b3d6758269aad07c |
> |   |   adminURL: http://192.168.122.64:8774/v2/
> e5ec75ca491049b2b3d6758269aad07c|
> |   |
> |
> | name  | nova
> |
> | type  | compute
> |
> +---+---
> +
>
> 1. After I deep into the code, and have a question : How to get/set the 
> context.project_id?
>
>
>
> [root@ospp9-ctrl1 site-packages(keystone_admin)]# vim
> nova/api/openstack/wsgi.py +721
> ```python
>project_id = action_args.pop("project_id", None)
> context = request.environ.get('nova.context')
> if (context and project_id and (project_id != context.project_id)):
> msg = _("Malformed request URL: URL's project_id
> '%(project_id)s'"
> " doesn't match Context's project_id"
> " '%(context_project_id)s'") % \
> {'project_id': project_id,
>  'context_project_id': context.project_id}
> return Fault(webob.exc.HTTPBadRequest(explanation=msg))
> ```
>
> 2. Why  got empty SeviceCatalog"serviceCatalog": []" but  it is not
> in official docs
> http://developer.openstack.org/api-guide/quick-start/api-
> quick-start.html#openstack-api-quick-guide
>
> --
> 
> Margin Hu
> Love Open Source Software.
> Mobile: (86) 186-8035-6499
> email : jhu_...@outlook.com
> github: http://github.com/todaygood
>  ---
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Requirements] [Horizon] upper-constraints shenanigans and development milestones

[Ian Cordasco]

> On Dec 9, 2016, at 4:47 PM, Richard Jones  wrote:
> 
> Hi folks,
> 
> We in Horizon land are looking to update to a new version of one of
> our dependencies, Angular Bootstrap version 2.2.0. We do this through
> xstatic packaging, so the release we'll be making is actually
> xstatic-angular-bootstrap 2.2.0.0
> 
> This release is backward incompatible and breaks Horizon in many ways.
> We already have a compatibility patch in review to get us up to speed
> in Ocata, but prior versions of Horizon would break without
> upper-constraints protections. We've recently pushed through several
> changes to stable Mitaka to get those protections in place - Newton
> was already protected.
> 
> The problem is that we'll have two Ocata milestone releases out when
> 2.2.0.0 is released, and those will break because we currently pull in
> *master* upper-constraints for the milestone releases, rather than a
> stable/ocata branch of upper-constraints - there is no stable/ocata
> branch of upper-constraints yet.
> 
> Has the idea of branching at development milestones been raised previously?

Hi Richard :)

I'm not sure it has, but I'm rather certain it's not tenable. Now that you 
bring this up, Horizon isn't the only project that will get bit by this - 
Glance will too. (Until recently Glance's tests were not happy with the newest 
version(s) of oslo.log)

I don't think *branching* is the solution here, but perhaps tagging/releasing 
the requirements repository like we do other projects would be. That said, this 
introduces a significant amount more work for milestone releases. Here's how I 
imagine it would have to work:

openstack/requirements enters a freeze period leading up to a milestone. It 
tags it's Pike-1 milestone. This triggers the Requirements Bot to go around and 
update the constraints URL to the Pike-1 tag instead of "master". Once those 
are successfully merged, other projects releasing following the 
cycle-with-milestones release tag would then be able to create they own Pike-1 
tag. After a successful release, cores would have to update their tox.ini files 
to go back to master's constraints.

(And I'm not entirely certain we could get the proposal bot to ignore us 
switching constraints URLs back so that part may have to be manual too.)

The root of this discussion, however, seems to be around the idea that there 
are downstream consumers who are deploying OpenStack without 
distribution-provided packages (or using a deployment project) and who are 
using a rather naïve approach to dependency management. This is something that 
has come up within Glance as well recently (that each milestone needs to have 
certain restrictions).

Is there good evidence of this behavior anywhere? We've had trouble finding 
evidence of this happening in the real world with Glance and there's nothing in 
the project team guide that indicates the same level of support for milestone 
releases as for cycle releases.

--
Ian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack] Malformed request URL doesn't match Context's project_id

[Jun Hu]

Hi Guys:

My openstack version is Mitaka.  I want to use curl to call openstack API , but 
I met a issue. Can you help me ?

[root@ospp9-ctrl1 site-packages(keystone_demo)]# source ~/keystonerc_admin

[root@ospp9-ctrl1 site-packages(keystone_admin)]# curl -s -X POST 
$OS_AUTH_URL/tokens   -H "Content-Type: application/json" -d '{"auth": 
{"tenantName": "", "passwordCredentials": {"username": "'"$OS_USERNAME"'", 
"password": "'"$OS_PASSWORD"'"}}}'  | python -m json.tool
{
"access": {
"metadata": {
"is_admin": 0,
"roles": []
},
"serviceCatalog": [],
"token": {
"audit_ids": [
"RJrDyNfIShyKTmXu5IWZUw"
],
"expires": "2016-12-10T13:12:15Z",
"id": "80b3d146c5614c149ccf983b21d93055",
"issued_at": "2016-12-10T12:12:15.171884Z"
},
"user": {
"id": "ae11a07ef07e47bba4a91d1c3516ac01",
"name": "admin",
"roles": [],
"roles_links": [],
"username": "admin"
}
}
}
[root@ospp9-ctrl1 site-packages(keystone_admin)]# export 
OS_TOKEN=80b3d146c5614c149ccf983b21d93055
[root@ospp9-ctrl1 site-packages(keystone_admin)]# export 
OS_PROJECT_ID=e5ec75ca491049b2b3d6758269aad07c
[root@ospp9-ctrl1 site-packages(keystone_admin)]# curl -s -H 
"X-Auth-Token:$OS_TOKEN" 
http://192.168.122.64:8774/v2/e5ec75ca491049b2b3d6758269aad07c/flavors  | 
python -m json.tool
{
"badRequest": {
"code": 400,
"message": "Malformed request URL: URL's project_id 
'e5ec75ca491049b2b3d6758269aad07c' doesn't match Context's project_id 'None'"
}
}

[root@ospp9-ctrl1 site-packages(keystone_admin)]# openstack catalog show nova
+---+---+
| Field | Value 
|
+---+---+
| endpoints | RegionOne 
|
|   |   publicURL: 
http://192.168.122.64:8774/v2/e5ec75ca491049b2b3d6758269aad07c   |
|   |   internalURL: 
http://192.168.122.64:8774/v2/e5ec75ca491049b2b3d6758269aad07c |
|   |   adminURL: 
http://192.168.122.64:8774/v2/e5ec75ca491049b2b3d6758269aad07c|
|   |   
|
| name  | nova  
|
| type  | compute   
|
+---+---+

1. After I deep into the code, and have a question : How to get/set the 
context.project_id?


[root@ospp9-ctrl1 site-packages(keystone_admin)]# vim 
nova/api/openstack/wsgi.py +721
```python
   project_id = action_args.pop("project_id", None)
context = request.environ.get('nova.context')
if (context and project_id and (project_id != context.project_id)):
msg = _("Malformed request URL: URL's project_id '%(project_id)s'"
" doesn't match Context's project_id"
" '%(context_project_id)s'") % \
{'project_id': project_id,
 'context_project_id': context.project_id}
return Fault(webob.exc.HTTPBadRequest(explanation=msg))
```

2. Why  got empty SeviceCatalog"serviceCatalog": []" but  it is not in 
official docs

http://developer.openstack.org/api-guide/quick-start/api-quick-start.html#openstack-api-quick-guide


--

Margin Hu
Love Open Source Software.
Mobile: (86) 186-8035-6499
email : jhu_...@outlook.com
github: http://github.com/todaygood
 ---
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

Ocata-2 will be released next week and we've had little success
getting the priority patches reviewed, unfortunately. We have had some
wins though, getting the upper-constraints stability patches into
stable Mitaka, which means we can be more confident releasing the
angular-bootstrap 2.2.0 xstatic library, and getting us out of the
dark ages of angular-bootstrap! We've also seen the profiler developer
panel get added, which will help us nail down some of the performance
issues that have been difficult to diagnose.

So yes, we're planning on tagging Horizon Ocata-2 (b2) next week, and
very shortly afterwards we'll be releasing xstatic-angular-bootstrap
2.2.0.0, and rolling in the compatibility patch for that into Horizon.
Horizon will be broken for a few days while compatibility is merged,
appropriate files are released and upper-constraints is updated.
Apologies, but that's just how backwards-incompatibility rolls,
sometimes!

This week's meeting[1] saw us discussing some of the patches under
review, but mostly, we discussed what to do with the languishing
integration test suite. David Lyle, PTL of many cycles, argued
strongly that they were a lost cause, and there was general support
for removing them completely, and migrating UI / full stack level
tests over to tempest. We have a couple of folks who will be looking
into that.

We also talked a little about our microversions approach, and Rob and
I have been nutting through the design of the approach in the
microversions etherherpad[2] to come up with an approach described in
the blueprint[3]. There's some ground-work to be done (pulling in
min/max version information, matching it to the config), and then
patches like instance description support can start using that version
support check facility.

There was also a request to be more fine-grained in attaching
blueprints to patches - the old "angularlise identity panels"
blueprint was widely abused, and it's good to see the individual panel
work being divided up now, thanks everyone!

Finally, we had a short talk about the mascot, and how to send
feedback on it (which you need to do ASAP if you haven't already). The
feedback link is [4]


Have a great weekend!

Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-12-07-20.00.html
[2] https://etherpad.openstack.org/p/horizon-microversion-support
[3] https://blueprints.launchpad.net/horizon/+spec/microversion-support
[4] http://www.tinyurl.com/OSmascot

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev