Re: [openstack-dev] [all] Mitaka Design Summit - Proposed slot allocation

[Thierry Carrez]

Zhipeng Huang wrote:
> Do we have enough logistics for projects that are not in the schedule
> above but also want to have ad hoc sessions at the design summit venue?
> For example like in Paris we usually just grab a table and slap a card
> with project name on it.

Space is very limited (more like Paris than like Vancouver), but we have
a lunch room with roundtables which can be abused (outside lunch) for
ad-hoc discussions.

-- 
Thierry Carrez (ttx)

__
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-dev] [Nova] understanding SSL behavior

[Rahul Sharma]

Hi All,

I am trying to configure the endpoints to communicate over https. I am
trying to debug a particular behavior of code but unable to relate my
sequence of actions with the behavior of code. Kindly do guide me to
understand the below mentioned scenario.

For SSL, I have generated a self-signed CA cert and used it for signing CSR
request of host/controller. I placed the CA cert in the trusted-root
authority of my host and all the services work fine. They are able to talk
with each other over https. I was able to access the url
https://:8774
from anywhere.

I went ahead and modified the nova.conf and added ssl_ca_file in [DEFAULT]
section.
[DEFAULT]
...
ssl_ca_file=
ssl_cert_file=
ssl_key_file=
...

Nova services come up fine, but now I am unable to access the url
https://:8774.
If I again remove the ssl_ca_file from nova.conf, it again starts working
fine.

Looking at the code, I could see that its getting used in nova/wsgi.py.

if CONF.ssl_ca_file:
ssl_kwargs['ca_certs'] = ca_file
ssl_kwargs['cert_reqs'] = ssl.CERT_REQUIRED

I am missing some very basic thing here, can someone please help me to
understand the sequence of steps going on and what do I need to do to
communicate with the service. The service is running and listening on port
8774, but it looks like I might have to provide something else with the
request to communicate with the service. Since various other services would
be communicating with nova, do I need to configure some specific parameter
in those services? Any pointers would be really helpful.

Thanks.

*Rahul Sharma*
*MS in Computer Science, 2016*
College of Computer and Information Science, Northeastern University
Mobile:  801-706-7860
Email: rahulsharma...@gmail.com
Linkedin: www.linkedin.com/in/rahulsharmaait
__
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-dev] [Fuel][Plugins] Deployment order with custom role

[Igor Kalnitsky]

Hi Swann,

> However, we still need deployment order between independent
> plugins and it seems impossible to define the priorities

There's no such things like priorities for now.. perhaps we can
introduce some kind of anchors instead of priorities, but that's
another story.

Currently the only way to synchronize two plugins is to make one to
know about other one. That means you need to properly setup "requires"
field:

- id: my-plugin-b-task
  type: puppet
  role: [my-plugin-b-role]
  required_for: [post_deployment_end]
  requires: [post_deployment_start, PLUGIN-A-TASK]
  parameters:
puppet_manifest: some-puppet.pp
puppet_modules: /etc/puppet/modules
timeout: 3600
cwd: /

Thanks,
Igor

On Mon, Sep 7, 2015 at 11:31 AM, Swann Croiset  wrote:
> Hi fuelers,
>
> We're currently porting nearly all LMA plugins to the new plugin fwk 3.0.0
> to leverage custom role capabilities.
> That brings up a lot of simplifications for node assignment, disk
> management, network config, reuse core tasks and so on .. thanks to the fwk.
>
> However, we still need deployment order between independent plugins and it
> seems impossible to define the priorities [0] in deployment_tasks.yaml,
> The only way to preserve deployment order would be to keep tasks.yaml too.
>
> So, I'm wondering if this is the recommended solution to address plugins
> order deployment with plugin fwk 3.0.0?
> And furthermore if tasks.yaml will still be supported in future by the
> plugin fwk or if the fwk shouldn't evolve  by adding priorities definitions
> in deployment_tasks.yaml ?
>
> Thanks
>
> [0] https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
>
> __
> 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 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-dev] Scheduler hints, API and Objects

[Alex Xu]

> 在 2015年9月7日，上午8:27，Ken'ichi Ohmichi  写道：
> 
> f we allow customization of scheduler-hints like new filters,
> out-of-tree filters without microversions, API users cannot know
> available scheduler-hints parameter from microversions number.
> That will be helpful for API users that nova can provide available
> parameters with JSON-Home or somethi


I'm thinking we should distinguish the API discovery and Capabilities discovery.

The JSON-Home and JSON-Schema is used to API discovery.
The discovery of scheduler-hints enabled or not in the deployment is 
Capabilities discovery.

So this should be done by two parts.
1. JSON-Schema is used to Scheduler-hints API contract
2. Another Capabilities discovery API is used to discover whether hint enabled 
or not in the deployment.

For JSON-Schema, we should think the API contract as “The Scheduler Hints API 
only accept dict”. Then
each hint should have it own contract. Add scheduler filters add each own hints 
schema to the API schema
for API discovery. 

So now I think Ken’ichi propose https://review.openstack.org/#/c/220440 
  make sense to me. But the
hints whether enabled in the deployment should be done another way, A 
capabilities discover API.



__
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-dev] [Keystone][Glance] keystonemiddleware & multiple keystone endpoints

[joehuang]

Hello, Jamie, 

Thanks for your guide. If the item " include_service_catalog" is not 
configured, then the region name can be used to specify the region for the 
token validation.

But if I configure" include_service_catalog = False", then the token validation 
will be redirected to incorrect keystone server.

In multi-site cloud scenario, there are dozens of endpoints, it's reasonable to 
" include_service_catalog = False".

The log is attached here. 172.17.0.135:35357 and 172.17.0.36:35357 are KeyStone 
server, our intention is to use the local KeyStone server 172.17.0.135 for 
token validation, but it forward the request to 172.17.0.36, KeyStone server in 
another region. 

It seems that override endpoint is a better choice, just like what I did in the 
https://docs.google.com/document/d/1258g0VTC4wktevo2ymS7SaNhDeY8-S2QWY45them7ZM/edit,
 ( I just borrowed the configuration item auth_uri, so many close name of 
configuration item, confused ).

--- 

2015-09-07 09:02:16.257 242 DEBUG keystoneclient.session [-] REQ: curl -g -i -X 
GET http://172.17.0.135:35357 -H "Accept: application/json" -H "User-Agent
: python-keystoneclient" _http_log_request 
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
2015-09-07 09:02:16.280 242 DEBUG keystoneclient.session [-] RESP: [300] 
content-length: 595 vary: X-Auth-Token connection: keep-alive date: Mon, 07 Sep 
2
015 09:02:16 GMT content-type: application/json x-distribution: Ubuntu
RESP BODY: {"versions": {"values": [{"status": "stable", "updated": 
"2015-03-30T00:00:00Z", "media-types": [{"base": "application/json", "type": 
"applicat
ion/vnd.openstack.identity-v3+json"}], "id": "v3.4", "links": [{"href": 
"http://172.17.0.135:35357/v3/;, "rel": "self"}]}, {"status": "stable", 
"updated":
 "2014-04-17T00:00:00Z", "media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": [{"
href": "http://172.17.0.135:35357/v2.0/;, "rel": "self"}, {"href": 
"http://docs.openstack.org/;, "type": "text/html", "rel": "describedby"}]}]}}
 _http_log_response 
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:223
2015-09-07 09:02:16.280 242 DEBUG keystoneclient.auth.identity.v3 [-] Making 
authentication request to http://172.17.0.135:35357/v3/auth/tokens get_auth_r
ef /usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/v3.py:125
2015-09-07 09:02:19.382 242 DEBUG keystoneclient.session [-] REQ: curl -g -i -X 
GET http://172.17.0.36:35357 -H "Accept: application/json" -H "User-Agent:
 python-keystoneclient" _http_log_request 
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
2015-09-07 09:02:19.386 242 DEBUG keystoneclient.session [-] RESP: [300] 
content-length: 593 vary: X-Auth-Token connection: keep-alive date: Mon, 07 Sep 
2
015 09:02:19 GMT content-type: application/json x-distribution: Ubuntu
RESP BODY: {"versions": {"values": [{"status": "stable", "updated": 
"2015-03-30T00:00:00Z", "media-types": [{"base": "application/json", "type": 
"applicat
ion/vnd.openstack.identity-v3+json"}], "id": "v3.4", "links": [{"href": 
"http://172.17.0.36:35357/v3/;, "rel": "self"}]}, {"status": "stable", 
"updated":
"2014-04-17T00:00:00Z", "media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": [{"h
ref": "http://172.17.0.36:35357/v2.0/;, "rel": "self"}, {"href": 
"http://docs.openstack.org/;, "type": "text/html", "rel": "describedby"}]}]}}
 _http_log_response 
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:223
2015-09-07 09:02:19.387 242 DEBUG keystoneclient.session [-] REQ: curl -g -i -X 
GET http://172.17.0.36:35357/v3/auth/tokens?nocatalog -H "X-Subject-Token:
 {SHA1}6e306214e70d1c9547b2d22d6962cefb6354164f" -H "User-Agent: 
python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}f9014aa76c16
2b0db646b325daf813e258c8e2a5" _http_log_request 
/usr/lib/python2.7/dist-packages/keystoneclient/session.py:195
2015-09-07 09:02:19.492 242 DEBUG keystoneclient.session [-] RESP: [200] 
content-length: 491 x-subject-token: 
{SHA1}6e306214e70d1c9547b2d22d6962cefb635416
4f vary: X-Auth-Token x-distribution: Ubuntu connection: keep-alive date: Mon, 
07 Sep 2015 09:02:19 GMT content-type: application/json x-openstack-request
-id: req-c752beb4-c87b-4812-93dc-b2ea00fbf7b1
RESP BODY: {"token": {"methods": ["password"], "roles": [{"id": 
"a4935779c40f45d3ba7a8eeada0f7714", "name": "admin"}], "expires_at": 
"2015-09-07T09:02:20.
00Z", "project": {"domain": {"id": "default", "name": "Default"}, "id": 
"79185427679a44019d919ce34112c971", "name": "admin"}, "extras": {}, "user": {"
domain": {"id": "default", "name": "Default"}, "id": 
"3c94437bbd0a455d938ed1d95c7049d1", "name": "osadmin"}, "audit_ids": 
["t9QR8DxdSXiQjuJW-nYxfw"], "iss
ued_at": "2015-09-07T08:02:20.00Z"}}
 _http_log_response 

Re: [openstack-dev] [neutron] Fail to get ipv4 address from dhcp

[zhi]

hi, if you turn off the "ARP Spoofing" flag and restart the q-agt service.
Does vm can get IP successfully?

2015-09-06 17:03 GMT+08:00 Huan Xie :

>
>
> Hi all,
>
>
>
> I’m trying to deploy OpenStack environment using DevStack with latest
> master code.
>
> I use Xenserver + neutron, with ML2 plugins and VLAN type.
>
>
>
> The problem I met is that the instances cannot really get IP address (I
> use DHCP), although we can see the VM with IP from horizon.
>
> I have tcpdump from VM side and DHCP server side, I can get DHCP request
> packet from VM side but cannot see any request packet from DHCP server side.
>
> But after I reboot the q-agt, the VM can get IP successfully.
>
> Checking the difference before and after q-agt restart, all my seen are
> the flow rules about ARP spoofing.
>
>
>
> This is the q-agt’s br-int port, it is dom0’s flow rules and the bold part
> are new added
>
>
>
> NXST_FLOW reply (xid=0x4):
>
>cookie=0x824d13a352a4e216, duration=163244.088s, table=0,
> n_packets=93, n_bytes=18140, idle_age=4998, hard_age=65534, priority=0
> actions=NORMAL
>
> *cookie=0x824d13a352a4e216, duration=163215.062s, table=0, n_packets=7,
> n_bytes=294, idle_age=33540, hard_age=65534, priority=10,arp,in_port=5
> actions=resubmit(,24)*
>
>cookie=0x824d13a352a4e216, duration=163230.050s, table=0,
> n_packets=25179, n_bytes=2839586, idle_age=5, hard_age=65534,
> priority=3,in_port=2,dl_vlan=1023 actions=mod_vlan_vid:1,NORMAL
>
>cookie=0x824d13a352a4e216, duration=163236.775s, table=0,
> n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534,
> priority=2,in_port=2 actions=drop
>
>cookie=0x824d13a352a4e216, duration=163243.516s, table=23,
> n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0
> actions=drop
>
>cookie=0x824d13a352a4e216, duration=163242.953s, table=24,
> n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0
> actions=drop
>
> *cookie=0x824d13a352a4e216, duration=163215.636s, table=24, n_packets=7,
> n_bytes=294, idle_age=33540, hard_age=65534,
> priority=2,arp,in_port=5,arp_spa=10.0.0.6 actions=NORMAL*
>
>
>
> I cannot see other changes after reboot q-agt, but it seems these rules
> are only for ARP spoofing, however, the instance can get IP from DHCP.
>
> I also google for this problem, but failed to deal this problem.
>
> Is anyone met this problem before or has any suggestion about how to
> debugging for this?
>
>
>
> Thanks a lot
>
>
>
> BR//Huan
>
> __
> 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 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-dev] [magnum] Steps to upload magnum images

[Ton Ngo]

Thanks Hongbin for the useful info.
I don't see the "apply" link either.  It looks like the group is set to
"Invite Only", so I will need to ping Steve Dake.
Ton Ngo,



From:   Hongbin Lu 
To: "openstack-dev@lists.openstack.org"

Date:   09/06/2015 04:51 PM
Subject:[openstack-dev] [magnum] Steps to upload magnum images



Hi team,

As you may know, magnum is tested with pre-built Fedora Atomic images.
Basically, these images are standard atomic image with k8s packages
pre-installed. The images can be downloaded from fedorapeople.org [1]. In
most cases, you are able to test magnum by using images there. If you are
not satisfied by existing images, you are welcome to build a new image and
share it with the team. Here [2] is the instruction for how to build an new
atomic image. After you successfully build an image, you may want to upload
it to the public file server, which is what I am going to talk about.

Below are the steps to upload an image:
  1.   Register an account in here
  https://admin.fedoraproject.org/accounts/
  2.   Sign the contributor agreement (On the home page after you
  login: “My Account” -> “Contributor Agreement”).
  3.   Upload your public key (“My Account” -> “Public SSH Key”).
  4.   Apply to join the magnum group (“Join a group” -> search
  “magnum” -> “apply”). If you cannot find the “apply” link under
  “Status” (I didn’t), you can wait a few minutes or skip this step and
  ask Steven Dake to add you to the group instead.
  5.   Ping Steven Dake (std...@cisco.com) to approve your
  application.
  6.   After 30-60 minutes, you should be able to SSH to the file
  server (ssh @fedorapeople.org). Our images are stored
  in /srv/groups/magnum.

Notes on using the file server:
  · Avoid type “sudo …”.
  · Activities there are logged, so don’t expect any privacy.
  · Not all contents are allowed. Please make sure your
  uploaded contents are acceptable before uploading it.

[1] https://fedorapeople.org/groups/magnum/
[2]
https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-build-atomic-image.rst
__
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 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-dev] [Fuel][Plugins] Deployment order with custom role

[Swann Croiset]

Hi fuelers,

We're currently porting nearly all LMA plugins to the new plugin fwk 3.0.0
to leverage custom role capabilities.
That brings up a lot of simplifications for node assignment, disk
management, network config, reuse core tasks and so on .. thanks to the fwk.

However, we still need deployment order between independent plugins and it
seems impossible to define the priorities [0] in *deployment_tasks.yaml,*
The only way to preserve deployment order would be to keep *tasks.yaml *too.

So, I'm wondering if this is the recommended solution to address plugins
order deployment with plugin fwk 3.0.0?
And furthermore if *tasks.yaml* will still be supported in future by the
plugin fwk or if the fwk shouldn't evolve  by adding priorities definitions
in *deployment_tasks.yaml* ?

Thanks

[0] https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
__
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-dev] OpenStack support for Amazon Concepts - was Re: cloud-init IPv6 support

[John Garbutt]

On 7 September 2015 at 03:34, Sean M. Collins  wrote:
> On Sun, Sep 06, 2015 at 04:25:43PM EDT, Kevin Benton wrote:
>> So it's been pointed out that http://169.254.169.254/openstack is completed
>> OpenStack invented. I don't quite understand how that's not violating the
>> contract you said we have with end users about EC2 compatibility under the
>> restriction of 'no new stuff'.
>
> I think that is a violation. I don't think that allows us to make more
> changes, just because we've broken the contract once, so a second
> infraction is less significant.

I see the OpenStack part of the metadata service a different
interface, that happens to be accessed in a similar way to EC2.

>> If we added an IPv6 endpoint that the metadata service listens on, it would
>> just be another place that non cloud-init clients don't know how to talk
>> to. It's not going to break our compatibility with any clients that connect
>> to the IPv4 address.
>
> No, but if Amazon were to make a decision about how to implement IPv6 in
> EC2 and how to make the Metadata API service work with IPv6 we'd be
> supporting two implementations - the one we came up with and one for
> supporting the way Amazon implemented it.

Yes, thats the cost of moving first.
Honestly, I would assume we end up implementing two access routes, if
we support IPv6 first.

Thanks,
John

__
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-dev] OpenStack support for Amazon Concepts - was Re: cloud-init IPv6 support

[John Garbutt]

On 7 September 2015 at 01:02, Jim Rollenhagen  wrote:
>> On Sep 6, 2015, at 09:43, Monty Taylor  wrote:
>>> On 09/05/2015 06:19 PM, Sean M. Collins wrote:
 On Fri, Sep 04, 2015 at 04:20:23PM EDT, Kevin Benton wrote:
 Right, it depends on your perspective of who 'owns' the API. Is it
 cloud-init or EC2?

 At this point I would argue that cloud-init is in control because it would
 be a large undertaking to switch all of the AMI's on Amazon to something
 else. However, I know Sean disagrees with me on this point so I'll let him
 reply here.
>>>
>>>
>>> Here's my take:
>>>
>>> Cloud-Init is a *client* of the Metadata API. The OpenStack Metadata API
>>> in both the Neutron and Nova projects should all the details of the
>>> Metadata API that is documented at:
>>>
>>> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
>>>
>>> This means that this is a compatibility layer that OpenStack has
>>> implemented so that users can use appliances, applications, and
>>> operating system images in both Amazon EC2 and an OpenStack environment.
>>>
>>> Yes, we can make changes to cloud-init. However, there is no guarantee
>>> that all users of the Metadata API are exclusively using cloud-init as
>>> their client. It is highly unlikely that people are rolling their own
>>> Metadata API clients, but it's a contract we've made with users. This
>>> includes transport level details like the IP address that the service
>>> listens on.
>>>
>>> The Metadata API is an established API that Amazon introduced years ago,
>>> and we shouldn't be "improving" APIs that we don't control. If Amazon
>>> were to introduce IPv6 support the Metadata API tomorrow, we would
>>> naturally implement it exactly the way they implemented it in EC2. We'd
>>> honor the contract that Amazon made with its users, in our Metadata API,
>>> since it is a compatibility layer.
>>>
>>> However, since they haven't defined transport level details of the
>>> Metadata API, regarding IPv6 - we can't take it upon ourselves to pick a
>>> solution. It is not our API.
>>>
>>> The nice thing about config-drive is that we've created a new mechanism
>>> for bootstrapping instances - by replacing the transport level details
>>> of the API. Rather than being a link-local address that instances access
>>> over HTTP, it's a device that guests can mount and read. The actual
>>> contents of the drive may have a similar schema as the Metadata API, but
>>> I think at this point we've made enough of a differentiation between the
>>> EC2 Metadata API and config-drive that I believe the contents of the
>>> actual drive that the instance mounts can be changed without breaking
>>> user expectations - since config-drive was developed by the OpenStack
>>> community. The point being that we call it "config-drive" in
>>> conversation and our docs. Users understand that config-drive is a
>>> different feature.
>>
>> Another great part about config-drive is that it's scalable. At infra's 
>> application scale, we take pains to disable anyting in our images that might 
>> want to contact the metadata API because we're essentially a DDOS on it.
>
> So, I tend to think a simple API service like this should never be hard to 
> scale. Put a bunch of hosts behind a load balancer, boom, done. Even 1000 
> requests/s shouldn't be hard, though it may require many hosts, and that's 
> far beyond what infra would hit today.
>
> The one problem I have with config-drive is that it is static. I'd love for 
> systems like cloud-init, glean, etc, to be able to see changes to mounted 
> disks, attached networks, etc. Attaching things after the fact isn't 
> uncommon, and to make the user config the thing is a terrible experience. :(

While I would love to avoid the complexity of the metadata service,
its dynamic nature is the key bit you loose with config drive.

For example, our mechanism for passwords (sure, I wish everyone used
keys) uses the openstack metadata service as a two way communication
system. Add VIF is probably a better example.

Thanks,
John

PS
If we get the per instance keystone token 'injection' working
correctly using purely config drive, then instances could just
authenticate to the regular API, avoiding the need for the metadata
service in its current form, but thats probably a red herring at this
point in time.

>> config-drive being local to the hypervisor host makes it MUCH more stable at 
>> scale.
>>
>> cloud-init supports config-drive
>>
>> If it were up to me, nobody would be enablig the metadata API in new 
>> deployments.
>>
>> I totally agree that we should not make changes in the metadata API.
>>
>>> I've had this same conversation about the Security Group API that we
>>> have. We've named it the same thing as the Amazon API, but then went and
>>> made all the fields different, inexplicably. Thankfully, it's just the
>>> names of the fields, rather than being huge 

[openstack-dev] [Cinder] The devref for volume migration in Cinder

[Sheng Bo Hou]

Hi everyone interested in volume migration:

I have just drafted the devref for volume migration in Cinder. It consists 
of everything I can think of for the volume migration.

LINK: https://review.openstack.org/#/c/214941

For folks who have much experience in migration:
Help me check it to see if it is comprehensive and precise. If there is 
anything missing or confusing, please comment on it.

For folks who are not familiar with experience in migration:
Read the devref from the beginning to the end to see if you have got what 
volume migration is about, how to use, how to configure, etc. Check if it 
is clear and easy to understand.

Thank you very much.

Best wishes,
Vincent Hou (侯胜博)

Staff Software Engineer, Open Standards and Open Source Team, Emerging 
Technology Institute, IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com 
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
__
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-dev] [zaqar] Mitaka summit brainstorm

[Flavio Percoco]

Greetings,

A couple of weeks ago, the Zaqar team started brainstorming about
possible topics for the Mitaka summit. Now it is time to start
collecting those proposals in a single place[0] so that we can start
voting and selecting topics.

The next PTL will likely use this etherpad as a reference to create a
schedule for the summit.

Happy Brainstorming,
Flavio

[0] https://etherpad.openstack.org/p/Mitaka-Zaqar

--
@flaper87
Flavio Percoco


pgpqBfjBL5g7l.pgp
Description: PGP signature
__
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-dev] [Congress] bugs for liberty release

[Rui Chen]

I start to fix https://bugs.launchpad.net/congress/+bug/1492329
if I have enough time, I can allocate other one or two bugs.

2015-09-06 8:13 GMT+08:00 Zhou, Zhenzan :

> I have taken two, thanks.
>
> https://bugs.launchpad.net/congress/+bug/1492308
>
> https://bugs.launchpad.net/congress/+bug/1492354
>
>
>
> BR
>
> Zhou Zhenzan
>
> *From:* Tim Hinrichs [mailto:t...@styra.com]
> *Sent:* Friday, September 4, 2015 23:40
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [Congress] bugs for liberty release
>
>
>
> Hi all,
>
>
>
> I've found a few bugs that we could/should fix by the liberty release.  I
> tagged them with "liberty-rc".  If we could all pitch in, that'd be great.
> Let me know which ones you'd like to work on so I can assign them to you in
> launchpad.
>
>
>
> https://bugs.launchpad.net/congress/+bugs/?field.tag=liberty-rc
>
>
>
> Thanks,
>
> Tim
>
> __
> 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 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-dev] [all] Mitaka Design Summit - Proposed slot allocation

[John Garbutt]

On 4 September 2015 at 18:55, Jim Rollenhagen  wrote:
> On Fri, Sep 04, 2015 at 01:52:41PM +0200, Dmitry Tantsur wrote:
>> On 09/04/2015 12:14 PM, Thierry Carrez wrote:
>> >Hi PTLs,
>> >
>> >Here is the proposed slot allocation for every "big tent" project team
>> >at the Mitaka Design Summit in Tokyo. This is based on the requests the
>> >liberty PTLs have made, space availability and project activity &
>> >collaboration needs.
>> >
>> >We have a lot less space (and time slots) in Tokyo compared to
>> >Vancouver, so we were unable to give every team what they wanted. In
>> >particular, there were far more workroom requests than we have
>> >available, so we had to cut down on those quite heavily. Please note
>> >that we'll have a large lunch room with roundtables inside the Design
>> >Summit space that can easily be abused (outside of lunch) as space for
>> >extra discussions.
>> >
>> >Here is the allocation:
>> >
>> >| fb: fishbowl 40-min slots
>> >| wr: workroom 40-min slots
>> >| cm: Friday contributors meetup
>> >| | day: full day, morn: only morning, aft: only afternoon
>> >
>> >Neutron: 12fb, cm:day
>> >Nova: 14fb, cm:day
>> >Cinder: 5fb, 4wr, cm:day
>> >Horizon: 2fb, 7wr, cm:day
>> >Heat: 4fb, 8wr, cm:morn
>> >Keystone: 7fb, 3wr, cm:day
>> >Ironic: 4fb, 4wr, cm:morn
>> >Oslo: 3fb, 5wr
>> >Rally: 1fb, 2wr
>> >Kolla: 3fb, 5wr, cm:aft
>> >Ceilometer: 2fb, 7wr, cm:morn
>> >TripleO: 2fb, 1wr, cm:full
>> >Sahara: 2fb, 5wr, cm:aft
>> >Murano: 2wr, cm:full
>> >Glance: 3fb, 5wr, cm:full
>> >Manila: 2fb, 4wr, cm:morn
>> >Magnum: 5fb, 5wr, cm:full
>> >Swift: 2fb, 12wr, cm:full
>> >Trove: 2fb, 4wr, cm:aft
>> >Barbican: 2fb, 6wr, cm:aft
>> >Designate: 1fb, 4wr, cm:aft
>> >OpenStackClient: 1fb, 1wr, cm:morn
>> >Mistral: 1fb, 3wr
>> >Zaqar: 1fb, 3wr
>> >Congress: 3wr
>> >Cue: 1fb, 1wr
>> >Solum: 1fb
>> >Searchlight: 1fb, 1wr
>> >MagnetoDB: won't be present
>> >
>> >Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA)
>> >PuppetOpenStack: 2fb, 3wr
>> >Documentation: 2fb, 4wr, cm:morn
>> >Quality Assurance: 4fb, 4wr, cm:full
>> >OpenStackAnsible: 2fb, 1wr, cm:aft
>> >Release management: 1fb, 1wr (shared meetup with QA)
>> >Security: 2fb, 2wr
>> >ChefOpenstack: will camp in the lunch room all week
>> >App catalog: 1fb, 1wr
>> >I18n: cm:morn
>> >OpenStack UX: 2wr
>> >Packaging-deb: 2wr
>> >Refstack: 2wr
>> >RpmPackaging: 1fb, 1wr
>> >
>> >We'll start working on laying out those sessions over the available
>> >rooms and time slots. If you have constraints (I already know
>> >searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
>> >Manila with Cinder, Solum with Magnum...) please let me know, we'll do
>> >our best to limit them.
>> >
>>
>> Would be cool to avoid conflicts between Ironic and TripleO.
>
> I'd also like to save room for one Ironic/Nova session, and one
> Ironic/Neutron session.

I am thinking we could use a Nova slot for the Ironic + Nova session,
picking a slot when there is nothing scheduled for ironic (or
TripleO).

This will all be part of our regular Nova session selection process,
but honestly I hope we can schedule that one.

Thanks,
John

PS
This is to support reserving cross project topics, to things that
involve more than two projects.

__
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-dev] Scheduler hints, API and Objects

[Ken'ichi Ohmichi]

Hi Sylvain,

2015-09-04 19:56 GMT+09:00 Sylvain Bauza :
>
>
> Le 04/09/2015 12:18, Ken'ichi Ohmichi a écrit :
>
> Hi Alex,
>
> Thanks for  your comment.
> IMO, this idea is different from the extension we will remove.
> That is modularity for the maintenance burden.
> By this idea, we can put the corresponding schema in each filter.
>
>
>
> While I think it could be a nice move to have stevedore-loaded filters for
> the FilterScheduler due to many reasons, I actually wouldn't want to delay
> more than needed the compatibility change for the API validation relaxing
> the scheduler hints.
>
> In order to have a smooth transition, I'd rather just provide a change for
> using stevedore with the filters and weighters (even if the weighters are
> not using the API), and then once implemented, then do the necessary change
> on the API level like the one you proposed.
>
> In the meantime, IMHO we should accept rather sooner than later (meaning for
> Liberty) https://review.openstack.org/#/c/217727/
>
> Thanks for that good idea, I like it,

Thanks for your feedback :)

During the above idea implementation, I found a bug of API validation
for cell filter:
https://bugs.launchpad.net/nova/+bug/1492925

I feel now this way will exactly help us for maintaining the code.

Thanks
Ken Ohmichi

---

> 2015年9月4日(金) 19:04 Alex Xu :
>>
>> 2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi :
>>>
>>> Hi Andrew,
>>>
>>> Sorry for this late response, I missed it.
>>>
>>> 2015-06-25 23:22 GMT+09:00 Andrew Laski :
>>> > I have been growing concerned recently with some attempts to formalize
>>> > scheduler hints, both with API validation and Nova objects defining
>>> > them,
>>> > and want to air those concerns and see if others agree or can help me
>>> > see
>>> > why I shouldn't worry.
>>> >
>>> > Starting with the API I think the strict input validation that's being
>>> > done,
>>> > as seen in
>>> >
>>> > http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da,
>>> > is unnecessary, and potentially problematic.
>>> >
>>> > One problem is that it doesn't indicate anything useful for a client.
>>> > The
>>> > schema indicates that there are hints available but can make no claim
>>> > about
>>> > whether or not they're actually enabled.  So while a microversion bump
>>> > would
>>> > typically indicate a new feature available to an end user, in the case
>>> > of a
>>> > new scheduler hint a microversion bump really indicates nothing at all.
>>> > It
>>> > does ensure that if a scheduler hint is used that it's spelled properly
>>> > and
>>> > the data type passed is correct, but that's primarily useful because
>>> > there
>>> > is no feedback mechanism to indicate an invalid or unused scheduler
>>> > hint.  I
>>> > think the API schema is a poor proxy for that deficiency.
>>> >
>>> > Since the exposure of a hint means nothing as far as its usefulness, I
>>> > don't
>>> > think we should be codifying them as part of our API schema at this
>>> > time.
>>> > At some point I imagine we'll evolve a more useful API for passing
>>> > information to the scheduler as part of a request, and when that
>>> > happens I
>>> > don't think needing to support a myriad of meaningless hints in older
>>> > API
>>> > versions is going to be desirable.
>>> >
>>> > Finally, at this time I'm not sure we should take the stance that only
>>> > in-tree scheduler hints are supported.  While I completely agree with
>>> > the
>>> > desire to expose things in cross-cloud ways as we've done and are
>>> > looking to
>>> > do with flavor and image properties I think scheduling is an area where
>>> > we
>>> > want to allow some flexibility for deployers to write and expose
>>> > scheduling
>>> > capabilities that meet their specific needs.  Over time I hope we will
>>> > get
>>> > to a place where some standardization can happen, but I don't think
>>> > locking
>>> > in the current scheduling hints is the way forward for that.  I would
>>> > love
>>> > to hear from multi-cloud users here and get some input on whether
>>> > that's
>>> > crazy and they are expecting benefits from validation on the current
>>> > scheduler hints.
>>> >
>>> > Now, objects.  As part of the work to formalize the request spec sent
>>> > to the
>>> > scheduler there's an effort to make a scheduler hints object.  This
>>> > formalizes them in the same way as the API with no benefit that I can
>>> > see.
>>> > I won't duplicate my arguments above, but I feel the same way about the
>>> > objects as I do with the API.  I don't think needing to update and
>>> > object
>>> > version every time a new hint is added is useful at this time, nor do I
>>> > think we should lock in the current in-tree hints.
>>> >
>>> > In the end this boils down to my concern that the scheduling hints api
>>> > is a
>>> > really horrible user experience 

[openstack-dev] [Heat] Multi Node Stack - keystone federation

[SHTILMAN, Tomer (Tomer)]

Hi
Currently in heat we have the ability to deploy a remote stack on a different 
region using OS::Heat::Stack and region_name in the context

My question is regarding multi node , separate keystones, with keystone 
federation.
Is there an option in a HOT template to send a stack to a different node, using 
the keystone federation feature?
For example ,If I have two Nodes (N1 and N2) with separate keystones (and 
keystone federation), I would like to deploy a stack on N1 with a nested stack 
that will deploy on N2, similar to what we have now for regions
Thanks
__
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-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting this week. The meeting is being held tomorrow 
Tuesday UTC1200.

In other timezones the meeting is at:

EST 08:00 (Tue)
Japan 21:00 (Tue)
China 20:00 (Tue)
United Kingdom 13:00 (Tue)

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI 
__
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-dev] [Aodh][Gnocchi] Change of Launchpad ownership

[Julien Danjou]

Hi folks,

Per recent discussion with the team, and to reflect the fact that we
have different core reviewers group on Gerrit for
Ceilometer/Gnocchi/Aodh, I've implemented the same arrangements on
Launchpad.

There are now 2 new teams:

  https://launchpad.net/~aodh-drivers
  https://launchpad.net/~gnocchi-drivers

That owns and maintains those projects.

Cheers,
-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info


signature.asc
Description: PGP signature
__
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-dev] [all] Cross-Project meeting, Tue Sept 8th, 21:00 UTC

[John Garbutt]

Dear PTLs, cross-project liaisons and anyone else interested,

We'll have a cross-project meeting tomorrow at 21:00 UTC, with the
following agenda:

* Review past action items
* Team announcements (horizontal, vertical, diagonal)
* Base feature deprecation policy [1]
* Open discussion

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html

If you're from an horizontal team (Release management, QA, Infra, Docs,
Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and
have something to communicate to the other teams, feel free to abuse the
relevant sections of that meeting and make sure it gets #info-ed by the
meetbot in the meeting summary.

See you there !

For more details on this meeting, please see:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

Thanks,
johnthetubaguy

__
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-dev] [Fuel][Plugins] Deployment order with custom role

[Swann Croiset]

On Mon, Sep 7, 2015 at 11:12 AM, Igor Kalnitsky 
wrote:

> Hi Swann,
>
> > However, we still need deployment order between independent
> > plugins and it seems impossible to define the priorities
>
> There's no such things like priorities for now.. perhaps we can
> introduce some kind of anchors instead of priorities, but that's
> another story.
>
yes its another story for next release(s), anchors could reuse the actual
convention of ranges used (disk, network, software, monitoring)
that said I no sure anchors are sufficient, we still need priorities to
specify orders for independant and/or optional plugins (they don't know
each other)



> Currently the only way to synchronize two plugins is to make one to
> know about other one. That means you need to properly setup "requires"
> field:
>
> - id: my-plugin-b-task
>   type: puppet
>   role: [my-plugin-b-role]
>   required_for: [post_deployment_end]
>   requires: [post_deployment_start, PLUGIN-A-TASK]
>   parameters:
> puppet_manifest: some-puppet.pp
> puppet_modules: /etc/puppet/modules
> timeout: 3600
> cwd: /
>
> We thought about this solution _but_ in our case we cannot because the
plugin is optional and may not be installed/enabled. So I guess this will
break things if we reference in 'require' a nonexistent plugin-a-task.
For example with LMA plugins, the LMA-Collector plugin must be
deployed/installed before LMA-Infrastructure-Alerting plugin (to avoid
false alerts UNKNOWN state) but the last may not be enabled for the
deployment.

Thanks,
> Igor
>
>
About tasks.yaml, we must support it until an equivalent 'deployment order'
is implemented with plugin-custom-role feature.


> On Mon, Sep 7, 2015 at 11:31 AM, Swann Croiset 
> wrote:
> > Hi fuelers,
> >
> > We're currently porting nearly all LMA plugins to the new plugin fwk
> 3.0.0
> > to leverage custom role capabilities.
> > That brings up a lot of simplifications for node assignment, disk
> > management, network config, reuse core tasks and so on .. thanks to the
> fwk.
> >
> > However, we still need deployment order between independent plugins and
> it
> > seems impossible to define the priorities [0] in deployment_tasks.yaml,
> > The only way to preserve deployment order would be to keep tasks.yaml
> too.
> >
> > So, I'm wondering if this is the recommended solution to address plugins
> > order deployment with plugin fwk 3.0.0?
> > And furthermore if tasks.yaml will still be supported in future by the
> > plugin fwk or if the fwk shouldn't evolve  by adding priorities
> definitions
> > in deployment_tasks.yaml ?
> >
> > Thanks
> >
> > [0]
> https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
> >
> >
> __
> > 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 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 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-dev] [nova] Bug importance

[John Garbutt]

I have a feeling launchpad asked my to renew my membership of nova-bug
recently, and said it would drop me form the list if I didn't do that.

Not sure if thats intentional to keep the list fresh? Its the first I
knew about it.

Unsure, but that could be related?

Thanks,
John

On 6 September 2015 at 14:25, Gary Kotton  wrote:
> That works.
> Thanks!
>
> From: "dava...@gmail.com" 
> Reply-To: OpenStack List 
> Date: Sunday, September 6, 2015 at 4:10 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [nova] Bug importance
>
> Gary,
>
> Not sure what changed...
>
> On this page (https://bugs.launchpad.net/nova/) on the right hand side, do
> you see "Bug Supervisor" set to "Nova Bug Team"?  I believe "Nova Bug Team"
> is open and you can add yourself, so if you do not see yourself in that
> group, can you please add it and try?
>
> -- Dims
>
> On Sun, Sep 6, 2015 at 4:56 AM, Gary Kotton  wrote:
>>
>> Hi,
>> In the past I was able to set the importance of a bug. Now I am unable to
>> do this? Has the policy changed? Can someone please clarify. If the policy
>> has changed who is responsible for deciding the priority of a bug?
>> Thanks
>> Gary
>>
>> __
>> 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
>>
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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 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-dev] [nova][oslo][policy] oslo.policy adoption in Nova.

[Sergey Vilgelm]

Hi nova-team,

Jeffrey Zhang has updated his patch[1].
Dan Smith, Could you remove -2?

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



> On Aug 20, 2015, at 17:26, Sergey Vilgelm  wrote:
> 
> Nova-cores,
> Do you have any decision about the patch: 
> https://review.openstack.org/#/c/198065/ ?
> Dan Smith, Could you remove -2?
> Jeffrey Zhang, What is your opinion?
> 
> On Tue, Aug 4, 2015 at 12:26 AM, Doug Hellmann  wrote:
> Excerpts from Doug Hellmann's message of 2015-08-03 16:19:31 -0400:
> > Excerpts from Morgan Fainberg's message of 2015-08-04 06:05:56 +1000:
> > >
> > > > On Aug 4, 2015, at 05:49, Doug Hellmann  wrote:
> > > >
> > > > Excerpts from Sergey Vilgelm's message of 2015-08-03 22:11:50 +0300:
> > > >>> On Mon, Aug 3, 2015 at 9:37 PM, Doug Hellmann  
> > > >>> wrote:
> > > >>>
> > > >>> Making that function public may be the most expedient fix, but the
> > > >>> parser was made private for a reason, so before we expose it we
> > > >>> should understand why, and if there are alternatives (such as
> > > >>> creating a fixture in oslo.policy to do what the nova tests need).
> > > >>
> > > >> Probably we may extend the Rules class and add the similar functions 
> > > >> as a
> > > >> classmethod?
> > > >> I've created a patch for slo.policy as example[1]
> > > >
> > > > Well, my point was that the folks working on that library considered the
> > > > entire parser to be private. That could just be overly ambitious API
> > > > pruning, or there could be some underlying reason (like, the syntax may
> > > > be changing or we want apps to interact with APIs and not generate DSL
> > > > and feed it to the library). So we should find out about the reason
> > > > before looking for alternative places to expose the parser.
> > > >
> > >
> > > The idea is to have apis vs dsl generation. But we did a "everything 
> > > private that isnt clearly used" as a starting point. I would prefer to 
> > > not make this public and have a fixture instead. That said, i am not 
> > > hard-set against a change to make it public.
> >
> > It would be easy enough to provide a fixture, which would make it clear
> > that the API is meant for testing and not for general use. I see a
> > couple of options:
> >
> > 1. a fixture that takes some DSL text and creates a new Enforcer
> >instance populated with the rules based on parsing the text
> >
> > 2. a fixture that takes some DSL text *and* an existing Enforcer
> >instance and replaces the rules inside that Enforcer instance with the
> >rules represented by the DSL text
> >
> > Option 1 feels a little cleaner but option 2 is more like how Nova
> > is using parse_rule() now and may be easier to drop in.
> 
> Brant also pointed out on IRC that the Rules class already has a
> load_json() class method that invokes the parser, so maybe the thing to
> do is update nova's tests to use that method. A fixture would still be
> an improvement, but using the existing code will let us move ahead
> faster (assuming we've decided not to wait for the new features to be
> implemented).
> 
> Doug
> 
> >
> > Doug
> >
> > >
> > > > Doug
> > > >
> > > >>
> > > >> [1] https://review.openstack.org/#/c/208617/
> > > >
> > > > __
> > > > 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 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
> 
> 
> 
> -- 
> Thanks,
> Sergey Vilgelm
> OpenStack Software Engineer
> Mirantis Inc.
> Skype: sergey.vilgelm
> Phone: +36 70 512 3836


—
Sergey Vilgelm
OpenStack Software Engineer
Mirantis Inc.

__
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-dev] [sahara] FFE request for scheduler and suspend EDP job for sahara

[Vitaly Gridnev]

Hey!

>From my point of view, we definetly should not give FFE for
add-suspend-resume-ability-for-edp-jobs

spec,
because client side for this change is not included in official liberty
release.

By the way, I am not sure about FFE for enable-scheduled-edp-jobs
,
because it's not clear which progress of these blueprint. Implementation of
that consists with 2 patch-sets, and one of that marked as Work In Progress.


On Sun, Sep 6, 2015 at 7:18 PM, lu jander  wrote:

> Hi, Guys
>
>  I would like to request FFE for scheduler EDP job and suspend EDP job for
> sahara. these patches has been reviewed for a long time with lots of patch
> sets.
>
> Blueprint:
>
> (1)
> https://blueprints.launchpad.net/sahara/+spec/enable-scheduled-edp-jobs
> (2)
> https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs
>
>
> Spec:
>
> (1) https://review.openstack.org/#/c/175719/
> (2) https://review.openstack.org/#/c/198264/
>
>
> Patch:
>
> (1) https://review.openstack.org/#/c/182310/
> (2) https://review.openstack.org/#/c/201448/
>
>
> __
> 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
>
>


-- 
Best Regards,
Vitaly Gridnev
Mirantis, Inc
__
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-dev] [Fuel] Nominate Andrey Sledzinskiy for fuel-ostf core

[Tatyana Leontovich]

Fuelers,

I'd like to nominate Andrey Sledzinskiy for the fuel-ostf core team.
He’s been doing a great job in writing patches(support for detached
services ).
Also his review comments always have a lot of detailed information for
further improvements

http://stackalytics.com/?user_id=asledzinskiy=all_type=all=fuel-ostf

Please vote with +1/-1 for approval/objection.

Core reviewer approval process definition:
https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

-- 
Best regards,
Tatyana
__
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-dev] [puppet] weekly meeting #50

[Emilien Macchi]

Hello,

Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150908

Please add additional items you'd like to discuss.
If our schedule allows it, we'll make bug triage during the meeting.

Regards,
-- 
Emilien Macchi
__
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-dev] [mistral] Team meeting - 09/07/2015

[Renat Akhmerov]

Hi,

This is a reminder that we’ll have a team meeting today at #openstack-meeting 
IRC channel at 16.00 UTC.

Agenda:
* Review action items
* Current status (progress, issues, roadblocks, further plans)
* Wrapping up Liberty-3
* Open discussion

Feel free to add your topics to 
https://wiki.openstack.org/wiki/Meetings/MistralAgenda 
.

Renat Akhmerov
@ Mirantis Inc.



__
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-dev] [puppet] Parameters possible default value

[Yanis Guenane]

Hello,

Few weeks ago the patches needed for us to have a cleaner parameters default
management way of doing things have been merged [1].

After that each module have been updated so it could rely on this new
feature.
All but puppet-neutron[3] and puppet-glance[4] have their patch merged.

Following on this effort, here is the first review to try to converge to
what
we expected : https://review.openstack.org/#/c/221005/

Cinder has been picked as the Canary module, if it can make it there it can
make it everywhere :)

If you have any feedback, please provide them on the review


Thank you in advance,

[1]
https://github.com/openstack/puppet-openstacklib/commit/3b85306d042292713d0fd89fa508e0a0fbf99671
[2] https://review.openstack.org/#/c/209875/
[3] https://review.openstack.org/#/c/209894/

--
Yanis Guenane

On 08/06/2015 11:04 AM, Yanis Guenane wrote:
> Hi Andrew,
>
> Sorry for the delay in this answer
>
> On 07/30/2015 09:20 PM, Andrew Woodward wrote:
>> On Thu, Jul 30, 2015 at 3:36 AM Sebastien Badia  wrote:
>>
>>> On Mon, Jul 27, 2015 at 09:43:28PM (+), Andrew Woodward wrote:
 Sorry, I forgot to finish this up and send it out.

 #--SNIP--
 def absent_default(
   $value,
   $default,
   $unset_when_default = true,
 ){
   if ( $value == $default ) and $unset_when_default {
 # I cant think of a way to deal with this in a define so lets pretend
 # we can re-use this with multiple providers like we could if this
>>> was
 # in the actual provider.

 keystone_config {$name: ensure => absent,}
   } else {
 keystone_config {$name: value = $value,}
   }
 }

 # Usage:
 absent_default{'DEFAULT/foo': default => 'bar', value => $foo }
>>> Hi,
>>>
>>> Hum, but you want to add this definition in all our modules, or directly in
>>> openstacklib?
>>>
>> I only mocked it up in a puppet define, because its easier for me (my ruby
>> is terrible) It should be done by adding these kinds of extra providers to
>> the inifile provider override that Yanis proposed.
>>
>>
>>> In case of openstacklib, in which manner do you define the
>>> _config
>>> resource? (eg, generic def, but specialized resource).
>>>
 #--SNIP--

 (I threw this together and haven't tried to run it yet, so It might not
>>> run
 verbatim, I will create a test project with it to show it working)

 So In the long-term we should be able to add some new functionality to
>>> the
 inifile provider to simply just do this for us. We can add the 'default'
 and 'unset_when_default' parameter so that we can use them straight w/o a
 wrapping function (but the warping function could be used too). This
>>> would
 give us the defaults (I have an idea on that too that I will try to put
 into the prototype) that should allow us to have something that looks
>>> quite
 clean, but is highly functional

> Keystone_config{unset_when_default => true} #probably flatly enabled in
 our inifile provider for the module
> keystone_config {'DEFAULT/foo': value => 'bar', default => 'bar'}
>>> I'm not sure to see the difference with the Yanis solution here¹, and not
>>> sure
>>> to see the link between the define resource and the type/provider resource.
>>>
>> This adds on to Yanis' solution so that we can authoritatively understand
>> what the default value is, and how it should be treated (instead of hoping
>> some magic word doesn't conflict)
> So I think we agree on most points here. '' value has
> been chosen based on our weekly meetings two weeks ago but it remains
> customizable (via the ensure_absent_val parameter).
>
> We need an explicit one by default so it can be set as a default value
> in all manifests.
>
> We mainly picked that value because we thought it was the less likely to
> be used as a valid value in any OpenStack related component
> configuration file.
>
> If by any chance it turns out to be a valid value for a parameter, we
> can use the temporary fix of changing ensure_absent_val for this
> specific parameter and raise the point during a meeting.
>
> I take the point to make it clear in the README that if a X_config
> resource has as a value set to '' it will ensure absent
> on the resource.
>
> Does that sound good with you ?
>
>> Seb
>>> ¹https://review.openstack.org/#/c/202574/
>>> --
>>> Sebastien Badia
>>> __
>>> 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 Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> 

Re: [openstack-dev] [mistral][yaql] Addressing task result using YAQL function

[Stan Lagun]

I believe this is a good change. $.task_name requires you that $ be
pointing to a tasks dictionary. But in the middle of the query like
[1.2.3].select($ + 1)  "$" will change its value. With a function approach
you can write [1, 2, 3].select($ + task(taskName)). However the name "task"
looks confusing as to my understanding tasks may have attributes other than
result. It may make sense to use task(taskName).result instead.

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis



On Sun, Sep 6, 2015 at 12:14 AM, Dmitri Zimine 
wrote:

> Yes meant to ask for consistency of referencing to task results. So it’s
> task(task_name) regardless of where.
>
> One use case in favor of this is tooling: I refactor workflow with an
> automated tool which wants to automatically rename the task name
> EVERYWHERE. You guys know well by now that renaming the task is a source of
> too many frustrating errors :)
>
> What other think?
>
> DZ.
>
> On Sep 3, 2015, at 4:23 AM, Renat Akhmerov  wrote:
>
>
> On 02 Sep 2015, at 21:01, Dmitri Zimine  wrote:
>
> Agree,
>
> with one detail: make it explicit -  task(task_name).
>
>
> So do you suggest we just replace res() with task() and it looks like
>
> task() - get task result when we are in “publish”
> task(task_name) - get task result from anywhere
>
> ?
>
> Is that correct you mean we must always specify a task name? The reason
> I’d like to have a simplified form (w/o task name) is that I see a lot of
> workflows that we have to repeat task name in publish so that it just look
> too verbose to me. Especially in case of very long task name.
>
> Consider something like this:
>
> tasks:
>   *get_volumes_by_names*:
> with-items: name in <% $.vol_names %>
> workflow: get_volume_by_name name=<% $.name %>
> publish:
>   volumes: <% $.*get_volumes_by_names* %>
>
> So in publish we have to repeat a task name, there’s no other way now. I’d
> like to soften this requirement, but if you still want to use task names
> you’ll be able to.
>
>
> res - we often see folks confused by result of what (action, task,
> workflow) although we cleaned up our lingo: action-output, task-result,
> workflow-output…. but still worth being explicit.
>
> And full result is being thought as the root context $.
>
> Publishing to global context may be ok for now, IMO.
>
>
> Not sure what you meant by "Publishing to global context”. Can you clarify
> please?
>
>
> Renat Akhmerov
> @ Mirantis Inc.
>
> __
> 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 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 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-dev] [Fuel][Plugins] Deployment order with custom role

[Igor Kalnitsky]

> that said I no sure anchors are sufficient, we still need priorities to
> specify orders for independant and/or optional plugins (they don't know
> each other)

If you need this, you're probably doing something wrong. Priorities
won't solve your problem here, because plugins will need to know about
priorities in other plugins and that's weird. The only working
solution here is to make plugin to know about other plugin if it's
important to make deployment precisely after other plugin.

> So I guess this will break things if we reference in 'require' a
> nonexistent plugin-a-task.

That's true. I think the right case here is to implement some sort of
conditional tasks, so different tasks will be executed in different
cases.

> About tasks.yaml, we must support it until an equivalent 'deployment order'
> is implemented with plugin-custom-role feature.

This is not about plugin-custom-role, this is about our task
deployment framework. I heard there were some plans on its
improvements.

Regards,
Igor

On Mon, Sep 7, 2015 at 3:27 PM, Swann Croiset  wrote:
>
>
> On Mon, Sep 7, 2015 at 11:12 AM, Igor Kalnitsky 
> wrote:
>>
>> Hi Swann,
>>
>> > However, we still need deployment order between independent
>> > plugins and it seems impossible to define the priorities
>>
>> There's no such things like priorities for now.. perhaps we can
>> introduce some kind of anchors instead of priorities, but that's
>> another story.
>
> yes its another story for next release(s), anchors could reuse the actual
> convention of ranges used (disk, network, software, monitoring)
> that said I no sure anchors are sufficient, we still need priorities to
> specify orders for independant and/or optional plugins (they don't know each
> other)
>
>
>>
>> Currently the only way to synchronize two plugins is to make one to
>> know about other one. That means you need to properly setup "requires"
>> field:
>>
>> - id: my-plugin-b-task
>>   type: puppet
>>   role: [my-plugin-b-role]
>>   required_for: [post_deployment_end]
>>   requires: [post_deployment_start, PLUGIN-A-TASK]
>>   parameters:
>> puppet_manifest: some-puppet.pp
>> puppet_modules: /etc/puppet/modules
>> timeout: 3600
>> cwd: /
>>
> We thought about this solution _but_ in our case we cannot because the
> plugin is optional and may not be installed/enabled. So I guess this will
> break things if we reference in 'require' a nonexistent plugin-a-task.
> For example with LMA plugins, the LMA-Collector plugin must be
> deployed/installed before LMA-Infrastructure-Alerting plugin (to avoid false
> alerts UNKNOWN state) but the last may not be enabled for the deployment.
>
>> Thanks,
>> Igor
>>
>
> About tasks.yaml, we must support it until an equivalent 'deployment order'
> is implemented with plugin-custom-role feature.
>
>>
>> On Mon, Sep 7, 2015 at 11:31 AM, Swann Croiset 
>> wrote:
>> > Hi fuelers,
>> >
>> > We're currently porting nearly all LMA plugins to the new plugin fwk
>> > 3.0.0
>> > to leverage custom role capabilities.
>> > That brings up a lot of simplifications for node assignment, disk
>> > management, network config, reuse core tasks and so on .. thanks to the
>> > fwk.
>> >
>> > However, we still need deployment order between independent plugins and
>> > it
>> > seems impossible to define the priorities [0] in deployment_tasks.yaml,
>> > The only way to preserve deployment order would be to keep tasks.yaml
>> > too.
>> >
>> > So, I'm wondering if this is the recommended solution to address plugins
>> > order deployment with plugin fwk 3.0.0?
>> > And furthermore if tasks.yaml will still be supported in future by the
>> > plugin fwk or if the fwk shouldn't evolve  by adding priorities
>> > definitions
>> > in deployment_tasks.yaml ?
>> >
>> > Thanks
>> >
>> > [0]
>> > https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
>> >
>> >
>> > __
>> > 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 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 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 Development Mailing List (not for 

[openstack-dev] [Infra] Meeting Tuesday September 8th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday September 8th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-01-19.01.log.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-01-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-01-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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-dev] [mistral][yaql] Addressing task result using YAQL function

[Renat Akhmerov]

> On 07 Sep 2015, at 19:18, Stan Lagun  wrote:
> 
> I believe this is a good change. $.task_name requires you that $ be pointing 
> to a tasks dictionary. But in the middle of the query like [1.2.3].select($ + 
> 1)  "$" will change its value. With a function approach
> you can write [1, 2, 3].select($ + task(taskName)). However the name "task" 
> looks confusing as to my understanding tasks may have attributes other than 
> result. It may make sense to use task(taskName).result instead.

Yes, I like the idea that task() should be more than just a result. Good point!

Renat Akhmerov
@ Mirantis Inc.


__
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-dev] [mistral] Team meeting minutes

[Nikolay Makhotkin]

Thanks for joining the meeting today!

Meeting minutes:
*http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-09-07-16.00.html
*
Meeting log: 
*http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-09-07-16.00.log.html
*

The next meeting will be on Sept 14. You can post your agenda items at
https://wiki.openstack.org/wiki/Meetings/MistralAgenda

-- 
Best Regards,
Nikolay
__
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-dev] Getting Started : OpenStack

[Bhagyashree Uday]

Hi ,

I am Bhagyashree from India(IRC nick : bee2502 ). I have previous
experience in data analytics including Machine Leraning,,NLP,IR and User
Experience Research. I am interested in contributing to OpenStack on
projects involving data analysis. Also , if these projects could be a part
of Outreachy, it would be added bonus. I went through project ideas listed
on https://wiki.openstack.org/wiki/Internship_ideas and one of these
projects interested me a lot -
Understand OpenStack Operations via Insights from Logs and Metrics: A Data
Science Perspective
However, this project does not have any mentioned mentor and I was hoping
you could provide me with some individual contact from OpenStack community
who would be interested in mentoring this project or some mailing
list/thread/IRC community where I could look for a mentor. Other open data
science projects/idea suggestions are also welcome.

Regards,
Bhagyashree
__
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-dev] [sahara] FFE request for scheduler and suspend EDP job for sahara

[lu jander]

Hi Vitaly,
enable-scheduled-edp-jobs

patch has 34 patch sets review. https://review.openstack.org/#/c/182310/ ,
it has no impact with another working in process patch.

2015-09-07 18:48 GMT+08:00 Vitaly Gridnev :

> Hey!
>
> From my point of view, we definetly should not give FFE for
> add-suspend-resume-ability-for-edp-jobs
> 
>  spec,
> because client side for this change is not included in official liberty
> release.
>
> By the way, I am not sure about FFE for enable-scheduled-edp-jobs
> ,
> because it's not clear which progress of these blueprint. Implementation of
> that consists with 2 patch-sets, and one of that marked as Work In Progress.
>
>
> On Sun, Sep 6, 2015 at 7:18 PM, lu jander  wrote:
>
>> Hi, Guys
>>
>>  I would like to request FFE for scheduler EDP job and suspend EDP job
>> for sahara. these patches has been reviewed for a long time with lots of
>> patch sets.
>>
>> Blueprint:
>>
>> (1)
>> https://blueprints.launchpad.net/sahara/+spec/enable-scheduled-edp-jobs
>> (2)
>> https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs
>>
>>
>> Spec:
>>
>> (1) https://review.openstack.org/#/c/175719/
>> (2) https://review.openstack.org/#/c/198264/
>>
>>
>> Patch:
>>
>> (1) https://review.openstack.org/#/c/182310/
>> (2) https://review.openstack.org/#/c/201448/
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Best Regards,
> Vitaly Gridnev
> Mirantis, Inc
>
> __
> 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 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-dev] [Fuel][Plugins] add health check for plugins

[Andrey Danin]

Hi.

Sorry for bringing this thread back from the grave but it look quite
interesting to me.

Sheena, could you please explain how pre-deployment sanity checks should
look like? I don't get what it is.

>From the Health Check point of view plugins may be divided to two groups:

1) A plugin that doesn't change an already covered functionality thus
doesn't require extra tests implemented. Such plugins may be Contrail and
almost all SDN plugins, Glance or Cinder backend plugins, and others which
don't bring any changes in OSt API or any extra OSt components.

2) A plugin that adds new elements into OSt or changes API or a standard
behavior. Such plugins may be Contrail (because it actually adds Contrail
Controller which may be covered by Health Check too), Cisco ASR plugin
(because it always creates HA routers), some Swift plugins (we don't have
Swift/S3 API covered by Health Check now at all), SR-IOV plugins (because
they require special network preparation and extra drivers to be presented
in an image), when a combination of different ML2 plugins or hypervisors
deployed (because you need to test all network underlayers or HVs).

So, all that means we need to make OSTF extendible by Fuel plugin's tests
eventually.


On Mon, Aug 10, 2015 at 5:17 PM, Sheena Gregson 
wrote:

> I like that idea a lot – I also think there would be value in adding
> pre-deployment sanity checks that could be called from the Health Check
> screen prior to deployment.  Thoughts?
>
>
>
> *From:* Simon Pasquier [mailto:spasqu...@mirantis.com]
> *Sent:* Monday, August 10, 2015 9:00 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for
> plugins
>
>
>
> Hello Samuel,
>
> This looks like an interesting idea. Do you have any concrete example to
> illustrate your point (with one of your plugins maybe)?
>
> BR,
>
> Simon
>
>
>
> On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel <
> samuel.bartel@gmail.com> wrote:
>
> Hi all,
>
>
>
> actually with fuel plugins there are test for the plugins used by the
> CICD, but after a deployment it is not possible for the user to easily test
> if a plugin is crrectly deploy or not.
>
> I am wondering if it could be interesting to improve the fuel plugin
> framework in order to be able to define test for each plugin which would ba
> dded to the health Check. the user would be able to test the plugin when
> testing the deployment test.
>
>
>
> What do you think about that?
>
>
>
>
>
> Kind regards
>
>
>
> Samuel
>
>
> __
> 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 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
>
>


-- 
Andrey Danin
ada...@mirantis.com
skype: gcon.monolake
__
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-dev] [puppet][keystone] plan for domain name handling

[Rich Megginson]

This is to outline the plan for the implementation of "puppet-openstack 
will support Keystone domain scoped resource names

without a '::domain' in the name, only if the 'default_domain_id'
parameter in Keystone has _not_ been set.  That is, if the default
domain is 'Default'."

Details here:
http://lists.openstack.org/pipermail/openstack-dev/2015-August/072878.html

In the process of implementation, several bugs were found and fixed (for 
review) in the underlying code.

https://bugs.launchpad.net/puppet-keystone/+bug/1492843
- review https://review.openstack.org/221119
https://bugs.launchpad.net/puppet-keystone/+bug/1492846
- review https://review.openstack.org/221120
https://bugs.launchpad.net/puppet-keystone/+bug/1492848
- review https://review.openstack.org/221121

I think the best course of action will be to rebase both 
https://review.openstack.org/#/c/218044 and 
https://review.openstack.org/#/c/218059/ on top of these, in order for 
the https://review.openstack.org/#/c/218059 to be able to pass the gate 
tests.


The next step will be to get rid of the introspection/indirection calls, 
which were a mistake from the beginning (terrible for performance), but 
that will be easily done on top of the above patches.
__
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-dev] [Ceilometer][Aodh] event-alarm fire policy

[Zhai, Edwin]

All,
Currently, event-alarm is one-shot style: don't fire again for same event.  But 
threshold-alarm is limited periodic style:

1. only get 1 fire for continuous valid datapoints.
2. Would get a new fire if insufficient data followed by valid ones, as we reset 
alarm state upon insufficient data.


So maybe event-alarm should be periodic also. But I'm not sure when to reset the 
alarm state to 'UNKNOWN': after each fire, or when receive different event.


Fire a bug @
https://bugs.launchpad.net/aodh/+bug/1493171

Best Rgds,
Edwin

__
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-dev] [keystone] FFE Request for Reseller

[Rodrigo Duarte]

Hi all,

Although Steve is right about the amount of code that needs to land, the
code has received lots of iterations on top of it. If the team don't agree
in landing the whole patch chain, maybe agree with a reasonable cut for
Liberty (more 3 or 4 patches, for example) so we have good prospects for M.

Thanks,

On Sun, Sep 6, 2015 at 2:23 AM, Steve Martinelli 
wrote:

> I suspect we'll vote on this topic during the next meeting on Tuesday, but
> this seems like a huge amount of code to land.
>
> Thanks,
>
> Steve Martinelli
> OpenStack Keystone Core
>
> [image: Inactive hide details for Henrique Truta ---2015/09/04 12:12:47
> PM---Hi Folks, As you may know, the Reseller Blueprint was prop]Henrique
> Truta ---2015/09/04 12:12:47 PM---Hi Folks, As you may know, the Reseller
> Blueprint was proposed and approved in Kilo (
>
> From: Henrique Truta 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 2015/09/04 12:12 PM
> Subject: [openstack-dev] [keystone] FFE Request for Reseller
> --
>
>
>
> Hi Folks,
>
>
> As you may know, the Reseller Blueprint was proposed and approved in Kilo (
> *https://review.openstack.org/#/c/139824/*
> ) with the developing postponed
> to Liberty.
>
> During this time, the 3 main patches of the chain were split into 8,
> becoming smaller and easier to review. The first 2 of them were merged
> before liberty-3 freeze, and some of the others have already received +2s.
> The code is very mature, having a keystone core member support through the
> whole release cycle.
>
>
> I would like to request an FFE for the remaining 9 patches (reseller core)
> which are already in review (starting from
> *https://review.openstack.org/#/c/213448/*
>  to
> *https://review.openstack.org/#/c/161854/*
> ).
>
>
> Henrique
> __
> 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 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
>
>


-- 
Rodrigo Duarte Sousa
MSc in Computer Science
http://rodrigods.com 
__
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-dev] [keystone]how to get service_catalog

[Jamie Lennox]

- Original Message -

> From: "王华" 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Sent: Tuesday, 8 September, 2015 11:36:15 AM
> Subject: Re: [openstack-dev] [keystone]how to get service_catalog

> Hi Jamie,

> We want to reuse the user token in magnum. But there is no convenient way to
> reuse it. It is better that we can use ENV['keystone.token_auth'] to init
> keystoneclient directly. Now we need to construct a auth_ref which is a
> parameter in keystoneclient init function according to
> ENV['keystone.token_auth']. I think it is a common case which service wants
> to reuse user token to do something like getting service_catalog. Can
> keystoneclient provide this feature?

> Regards,
> Wanghua

Yes, that's exactly what ENV['keystone.token_auth'] is for. 

You would need to create a session object [1] which can be on the process (long 
lived). Then when you create a client you pass Client(session=sess, 
auth=ENV['keystone.token_auth']). This works for all the clients i know of with 
the exception of swift. This will reuse the user's auth token and the user's 
service catalog. 

For keystone there is an issue with doing this with the client.Client() object 
as it still wants a URL passed (there is a bug for this i can find if you're 
interested). If you are able to I recommend using client.v3.Client() directly. 

Jamie 

[1] 
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/session.py#L845
 

> On Mon, Sep 7, 2015 at 12:54 PM, Jamie Lennox < jamielen...@redhat.com >
> wrote:

> > - Original Message -
> 
> > > From: "王华" < wanghua.hum...@gmail.com >
> 
> > > To: "OpenStack Development Mailing List (not for usage questions)" <
> > > openstack-dev@lists.openstack.org >
> 
> > > Sent: Monday, 7 September, 2015 12:00:43 PM
> 
> > > Subject: [openstack-dev] [keystone]how to get service_catalog
> 
> > >
> 
> > > Hi all,
> 
> > >
> 
> > > When I use a token to init a keystoneclient and try to get
> > > service_catalog
> > > by
> 
> > > it, error occurs. I find that keystone doesn't return service_catalog
> > > when
> 
> > > we use a token. Is there a way to get service_catalog by token? In
> > > magnum,
> 
> > > we now make a trick. We init a keystoneclient with service_catalog which
> > > is
> 
> > > contained in the token_info returned by keystonemiddleware in auth_ref
> 
> > > parameter.
> 
> > >
> 
> > > I want a way to get service_catalog by token. Or can we init a
> > > keystoneclient
> 
> > > by the token_info return by keystonemiddleware directly?
> 
> > >
> 
> > > Regards,
> 
> > > Wanghua
> 

> > Sort of.
> 

> > The problem you are hitting is that a token is just a string, an identifier
> > for some information stored in keystone. Given a token at __init__ time the
> > client doesn't try to validate this in anyway it just assumes you know what
> > you are doing. You can do a variation of this though in which you use an
> > existing token to fetch a new token with the same rights (the expiry etc
> > will be the same) and then you will get a fresh service catalog. Using auth
> > plugins that's the Token family of plugins.
> 

> > However i don't _think_ that's exactly what you're looking for in magnum.
> > What token are you trying to reuse?
> 

> > If it's the users token then auth_token passes down an auth plugin in the
> > ENV['keystone.token_auth'] variable[1] and you can pass that to a client to
> > reuse the token and service catalog. If you are loading up magnum specific
> > auth then again have a look at using keystoneclient's auth plugins and
> > reusing it across multiple requests.
> 

> > Trying to pass around a bundle of token id and service catalog is pretty
> > much
> > exactly what an auth plugin does and you should be able to do something
> > there.
> 

> > Jamie
> 

> > [1]
> > https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L164
> 
> > > __
> 
> > > 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 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 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-dev] [keystone]how to get service_catalog

[王华]

Hi Jamie,

I find that when I use an existing token to fetch a new token with the same
rights (the expiry etc will be the same) , but keystone doesn't return
service_catalog in the response. I wonder why it is different from
authentication with password.

Regards,
Wanghua

On Tue, Sep 8, 2015 at 9:36 AM, 王华  wrote:

> Hi Jamie,
>
> We want to reuse the user token in magnum. But there is no convenient way
> to reuse it. It is better that we can use ENV['keystone.token_auth'] to
> init keystoneclient directly. Now we need to construct a auth_ref which is
> a parameter in keystoneclient init function according to
> ENV['keystone.token_auth']. I think it is a common case which service wants
> to reuse user token to do something like getting service_catalog. Can
> keystoneclient provide this feature?
>
> Regards,
> Wanghua
>
> On Mon, Sep 7, 2015 at 12:54 PM, Jamie Lennox 
> wrote:
>
>>
>>
>> - Original Message -
>> > From: "王华" 
>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> > Sent: Monday, 7 September, 2015 12:00:43 PM
>> > Subject: [openstack-dev] [keystone]how to get service_catalog
>> >
>> > Hi all,
>> >
>> > When I use a token to init a keystoneclient and try to get
>> service_catalog by
>> > it, error occurs. I find that keystone doesn't return service_catalog
>> when
>> > we use a token. Is there a way to get service_catalog by token? In
>> magnum,
>> > we now make a trick. We init a keystoneclient with service_catalog
>> which is
>> > contained in the token_info returned by keystonemiddleware in auth_ref
>> > parameter.
>> >
>> > I want a way to get service_catalog by token. Or can we init a
>> keystoneclient
>> > by the token_info return by keystonemiddleware directly?
>> >
>> > Regards,
>> > Wanghua
>>
>> Sort of.
>>
>> The problem you are hitting is that a token is just a string, an
>> identifier for some information stored in keystone. Given a token at
>> __init__ time the client doesn't try to validate this in anyway it just
>> assumes you know what you are doing. You can do a variation of this though
>> in which you use an existing token to fetch a new token with the same
>> rights (the expiry etc will be the same) and then you will get a fresh
>> service catalog. Using auth plugins that's the Token family of plugins.
>>
>> However i don't _think_ that's exactly what you're looking for in magnum.
>> What token are you trying to reuse?
>>
>> If it's the users token then auth_token passes down an auth plugin in the
>> ENV['keystone.token_auth'] variable[1] and you can pass that to a client to
>> reuse the token and service catalog. If you are loading up magnum specific
>> auth then again have a look at using keystoneclient's auth plugins and
>> reusing it across multiple requests.
>>
>> Trying to pass around a bundle of token id and service catalog is pretty
>> much exactly what an auth plugin does and you should be able to do
>> something there.
>>
>>
>> Jamie
>>
>> [1]
>> https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L164
>> >
>> __
>> > 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 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 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-dev] [keystone]how to get service_catalog

[王华]

Hi Jamie,

We want to reuse the user token in magnum. But there is no convenient way
to reuse it. It is better that we can use ENV['keystone.token_auth'] to
init keystoneclient directly. Now we need to construct a auth_ref which is
a parameter in keystoneclient init function according to
ENV['keystone.token_auth']. I think it is a common case which service wants
to reuse user token to do something like getting service_catalog. Can
keystoneclient provide this feature?

Regards,
Wanghua

On Mon, Sep 7, 2015 at 12:54 PM, Jamie Lennox 
wrote:

>
>
> - Original Message -
> > From: "王华" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Sent: Monday, 7 September, 2015 12:00:43 PM
> > Subject: [openstack-dev] [keystone]how to get service_catalog
> >
> > Hi all,
> >
> > When I use a token to init a keystoneclient and try to get
> service_catalog by
> > it, error occurs. I find that keystone doesn't return service_catalog
> when
> > we use a token. Is there a way to get service_catalog by token? In
> magnum,
> > we now make a trick. We init a keystoneclient with service_catalog which
> is
> > contained in the token_info returned by keystonemiddleware in auth_ref
> > parameter.
> >
> > I want a way to get service_catalog by token. Or can we init a
> keystoneclient
> > by the token_info return by keystonemiddleware directly?
> >
> > Regards,
> > Wanghua
>
> Sort of.
>
> The problem you are hitting is that a token is just a string, an
> identifier for some information stored in keystone. Given a token at
> __init__ time the client doesn't try to validate this in anyway it just
> assumes you know what you are doing. You can do a variation of this though
> in which you use an existing token to fetch a new token with the same
> rights (the expiry etc will be the same) and then you will get a fresh
> service catalog. Using auth plugins that's the Token family of plugins.
>
> However i don't _think_ that's exactly what you're looking for in magnum.
> What token are you trying to reuse?
>
> If it's the users token then auth_token passes down an auth plugin in the
> ENV['keystone.token_auth'] variable[1] and you can pass that to a client to
> reuse the token and service catalog. If you are loading up magnum specific
> auth then again have a look at using keystoneclient's auth plugins and
> reusing it across multiple requests.
>
> Trying to pass around a bundle of token id and service catalog is pretty
> much exactly what an auth plugin does and you should be able to do
> something there.
>
>
> Jamie
>
> [1]
> https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L164
> >
> __
> > 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 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 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-dev] [Glance] Artifacts meeting canceled today.

[Nikhil Komawar]

Hi,

We do not have any items to be discussed and nothing has been proposed
by requesters on the agenda etherpad. Also, being a holiday in the US we
are likely to have smaller participation.

Hence, the artifacts sub team meeting has been canceled for today. See
you all next time around! 

-- 

Thanks,
Nikhil


__
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-dev] Getting Started : OpenStack

[Victoria Martínez de la Cruz]

Hi Bhagyashree,

Welcome!

That project seems to belong to Ceilometer, but I'm not sure about that.
Ceilometer is the code name for OpenStack telemetry, if you are interested
about it a good place to start is https://wiki.openstack.org/wiki/Ceilometer
.

Those internships ideas are from previous Outreachy/Google Summer of Code
rounds. Outreachy applications will open next September 22nd so there is no
much information about next round mentors/projects yet.

Call for mentors is going to be launched soon, so keep track of that wiki
for updates. Feel free to pass by #openstack-opw as well and we can help
you set your development environment.

Cheers,

Victoria

2015-09-07 14:59 GMT-03:00 Bhagyashree Uday :

> Hi ,
>
> I am Bhagyashree from India(IRC nick : bee2502 ). I have previous
> experience in data analytics including Machine Leraning,,NLP,IR and User
> Experience Research. I am interested in contributing to OpenStack on
> projects involving data analysis. Also , if these projects could be a
> part of Outreachy, it would be added bonus. I went through project ideas
> listed on https://wiki.openstack.org/wiki/Internship_ideas and one of
> these projects interested me a lot -
> Understand OpenStack Operations via Insights from Logs and Metrics: A Data
> Science Perspective
> However, this project does not have any mentioned mentor and I was hoping
> you could provide me with some individual contact from OpenStack community
> who would be interested in mentoring this project or some mailing
> list/thread/IRC community where I could look for a mentor. Other open data
> science projects/idea suggestions are also welcome.
>
> Regards,
> Bhagyashree
>
> __
> 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 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