[openstack-dev] [Neutron] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Gal Sagie]

Hello All,

In OpenStack Tokyo summit we will have a design summit session for
containers networking
and containers orchestration engines integration with Neutron [1].

Please feel free to edit the session etherpad [2] with relevant topics, if
you are working
and have any gaps or needs from Neutron in that area, please share.

Even if we cant resolve everything in one session, i think it would be
great to at least understand
the problems and document them so we can address the needs and priorities
during the upcoming cycle.

Thanks
Gal.

[1]
http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViN7rLOY7CI
[2] https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration
__
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] [Neutron] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Armando M.]

Gal,

[2] is not meant to be edited by anyone just yet. This will lead to chaos
and an unproductive session. Once the link is out is obvious that anyone
can edit, but welcoming input is a recipe for disaster!

I appreciate the initiative, but please consider running thoughts by me for
advice.

Cheers,
Armando

On 18 October 2015 at 04:09, Gal Sagie  wrote:

> Hello All,
>
> In OpenStack Tokyo summit we will have a design summit session for
> containers networking
> and containers orchestration engines integration with Neutron [1].
>
> Please feel free to edit the session etherpad [2] with relevant topics, if
> you are working
> and have any gaps or needs from Neutron in that area, please share.
>
> Even if we cant resolve everything in one session, i think it would be
> great to at least understand
> the problems and document them so we can address the needs and priorities
> during the upcoming cycle.
>
> Thanks
> Gal.
>
> [1]
> http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViN7rLOY7CI
> [2] https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration
>
> __
> 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] [Neutron] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Armando M.]

Perhaps adding a section for 'collecting ideas' right at the bottom of the
etherpad will help directing input.

We should strive for keeping the session focussed, sessions are only 40
mins, and realistically we'll only have 30 mins to talk about the meaty
stuff. If we want to go through bullet by bullet, we'll need an entire
summit :)

Cheers,
Armando

On 18 October 2015 at 09:14, Armando M.  wrote:

> Gal,
>
> [2] is not meant to be edited by anyone just yet. This will lead to chaos
> and an unproductive session. Once the link is out is obvious that anyone
> can edit, but welcoming input is a recipe for disaster!
>
> I appreciate the initiative, but please consider running thoughts by me
> for advice.
>
> Cheers,
> Armando
>
> On 18 October 2015 at 04:09, Gal Sagie  wrote:
>
>> Hello All,
>>
>> In OpenStack Tokyo summit we will have a design summit session for
>> containers networking
>> and containers orchestration engines integration with Neutron [1].
>>
>> Please feel free to edit the session etherpad [2] with relevant topics,
>> if you are working
>> and have any gaps or needs from Neutron in that area, please share.
>>
>> Even if we cant resolve everything in one session, i think it would be
>> great to at least understand
>> the problems and document them so we can address the needs and priorities
>> during the upcoming cycle.
>>
>> Thanks
>> Gal.
>>
>> [1]
>> http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViN7rLOY7CI
>> [2] https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration
>>
>> __
>> 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] [Zaqar] Design Summit Schedule

[Fei Long Wang]

Hi everyone,

I just posted the Zaqar schedule for design summit:

https://mitakadesignsummit.sched.org/overview/type/zaqar

Please let me know if there is any schedule conflicts for you, so we can work 
out it on next weekly meeting.

Session Leaders: Please fill the etherpad on 
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Zaqar Thanks.

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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] [app-catalog][horizon] app-catalog-ui 1.0.0 release

[Christopher Aedo]

We are really excited to announce the first release of the Community
App Catalog UI for Horizon!

https://github.com/openstack/app-catalog-ui/tree/1.0.0

This is the first really big step forward for connecting the App
Catalog (https://apps.openstack.org) with individual clouds, making it
easier than ever for users to find apps and components for their
OpenStack environments.

We've got a Debian package available and will have an RDO package
available shortly as well, making it very easy for operators to
include the App Catalog panel in their Horizon deployment.  If you'd
like to check it out yourself we also have a Devstack plugin in the
repo that will let you take it for a test drive in a matter of
minutes.

Please let us know what you think!  We meet regularly on Thursdays
(1700 UTC on #openstack-meeting-3) and are always available on IRC at
#openstack-app-catalog.

-Christopher

__
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] [Neutron] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Murali R]

Will there be an irc opened for these sessions to join remotely?



On Sun, Oct 18, 2015 at 9:19 AM, Armando M.  wrote:

> Perhaps adding a section for 'collecting ideas' right at the bottom of the
> etherpad will help directing input.
>
> We should strive for keeping the session focussed, sessions are only 40
> mins, and realistically we'll only have 30 mins to talk about the meaty
> stuff. If we want to go through bullet by bullet, we'll need an entire
> summit :)
>
> Cheers,
> Armando
>
>
> On 18 October 2015 at 09:14, Armando M.  wrote:
>
>> Gal,
>>
>> [2] is not meant to be edited by anyone just yet. This will lead to chaos
>> and an unproductive session. Once the link is out is obvious that anyone
>> can edit, but welcoming input is a recipe for disaster!
>>
>> I appreciate the initiative, but please consider running thoughts by me
>> for advice.
>>
>> Cheers,
>> Armando
>>
>> On 18 October 2015 at 04:09, Gal Sagie  wrote:
>>
>>> Hello All,
>>>
>>> In OpenStack Tokyo summit we will have a design summit session for
>>> containers networking
>>> and containers orchestration engines integration with Neutron [1].
>>>
>>> Please feel free to edit the session etherpad [2] with relevant topics,
>>> if you are working
>>> and have any gaps or needs from Neutron in that area, please share.
>>>
>>> Even if we cant resolve everything in one session, i think it would be
>>> great to at least understand
>>> the problems and document them so we can address the needs and
>>> priorities during the upcoming cycle.
>>>
>>> Thanks
>>> Gal.
>>>
>>> [1]
>>> http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViN7rLOY7CI
>>> [2] https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration
>>>
>>>
>>> __
>>> 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] [Murano] py26 support in python-muranoclient

[Robert Collins]

On 11 October 2015 at 01:17, Jeremy Stanley  wrote:
> On 2015-10-09 18:51:51 + (+), Tim Bell wrote:
>> There is a need to distinguish between server side py26 support
>> which is generally under the control of the service provider and
>> py26 support on the client side. For a service provider to push
>> all of their hypervisors and service machines to RHEL 7 is under
>> their control but requiring all of their users to do the same is
>> much more difficult.
> [...]
>
> Agreed, this is why the master branches of clients/libraries opted
> to continue testing with Python 2.6 throughout the supported
> lifetime of the stable/juno branches. But much like for the service
> providers and users, continuing to run older Linux distributions
> (CentOS 6.x, Ubuntu 12.4.x) in our test infrastructure comes at a
> significant cost and at some point we need to free up our limited
> sysadmin resources to focus on better support for more recent distro
> releases.
>
> Once new patches to OpenStack projects are no longer actively tested
> on these older platforms, we have to expect that the ability to run
> new versions of the projects on them will quickly vanish. However,
> users on those older distro releases can opt to continue using
> whatever versions last supported them or perhaps fall back on the
> versions provided by their distro's package manager.

For pbr I'd actually value keeping 2.6 testing for a bit: because in
setup_requires we're not capped anywhere - and those folk that *are*
still using 2.6 shouldn't be broken by us - pbr is basically the last
thing that can sanely move.

I'd be happy with deadsnakes PPA on ubuntu, or a docker container or
whatever - just having the confidence that we haven't accidentally
broken anything until well past the point that the last release of a
higher level library is no longer accepting bug reports - that would
be the goal.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [Murano] py26 support in python-muranoclient

[Monty Taylor]

On 10/18/2015 04:52 PM, Robert Collins wrote:

On 11 October 2015 at 01:17, Jeremy Stanley  wrote:

On 2015-10-09 18:51:51 + (+), Tim Bell wrote:

There is a need to distinguish between server side py26 support
which is generally under the control of the service provider and
py26 support on the client side. For a service provider to push
all of their hypervisors and service machines to RHEL 7 is under
their control but requiring all of their users to do the same is
much more difficult.

[...]

Agreed, this is why the master branches of clients/libraries opted
to continue testing with Python 2.6 throughout the supported
lifetime of the stable/juno branches. But much like for the service
providers and users, continuing to run older Linux distributions
(CentOS 6.x, Ubuntu 12.4.x) in our test infrastructure comes at a
significant cost and at some point we need to free up our limited
sysadmin resources to focus on better support for more recent distro
releases.

Once new patches to OpenStack projects are no longer actively tested
on these older platforms, we have to expect that the ability to run
new versions of the projects on them will quickly vanish. However,
users on those older distro releases can opt to continue using
whatever versions last supported them or perhaps fall back on the
versions provided by their distro's package manager.


For pbr I'd actually value keeping 2.6 testing for a bit: because in
setup_requires we're not capped anywhere - and those folk that *are*
still using 2.6 shouldn't be broken by us - pbr is basically the last
thing that can sanely move.

I'd be happy with deadsnakes PPA on ubuntu, or a docker container or
whatever - just having the confidence that we haven't accidentally
broken anything until well past the point that the last release of a
higher level library is no longer accepting bug reports - that would
be the goal.


Maybe a non-voting job that adds the deadsnakes PPA and installs 2.6 in 
the job setup and then runs pbr tests with it.


I say non-voting because we'd be introducing a direct-internet consuming 
test, which increases the risk of failures - but given that the pbr team 
is already careful (given the nature of the project) an informational 
job should be good enough, no?



__
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] [Murano] py26 support in python-muranoclient

[Robert Collins]

On 19 October 2015 at 10:01, Monty Taylor  wrote:

>
> Maybe a non-voting job that adds the deadsnakes PPA and installs 2.6 in the
> job setup and then runs pbr tests with it.
>
> I say non-voting because we'd be introducing a direct-internet consuming
> test, which increases the risk of failures - but given that the pbr team is
> already careful (given the nature of the project) an informational job
> should be good enough, no?

Once we remove the dvsm jobs I think we'd be independent in terms of
pipeline - at that point I think the risk of a failure would be ok
since it wouldn't cascade.

But yeah, informational would be fine - we can socialise 'treat it as
voting' amongst the committers easily enough.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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-scheduler] Scheduler sub-group meeting - Canceled for 10/19

[Dugger, Donald D]

As discussed last week we will cancel this week's meeting to get ready for the 
summit.  See you all in Tokyo.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

__
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] Failed to create swarm baywithfedora-21-atomic-5-d181.qcow2

[Qiao,Liyong]

I co-worked with Mars last week, but in my environment I can not 
reproduce this issue.

I'v told my docker daemon line to Mars, but same errors.

one thing I forget to ask, it is same with hongbin's question:
if you need proxy to access internet, please add them in baymodel:

taget@taget-ThinkStation-P300:~/devstack$ magnum baymodel-create ...
--dns-nameserver 10.248.2.5 --coe swarm --fixed-network 192.168.0.0/24 
--http-proxy http://myhttpproxy:port/ --https-proxy 
https://myhttpsproxy:port/ --no-proxy 
192.168.0.1,192.168.0.2,192.168.0.3,192.168.0.4,192.168.0.5



On 2015年10月17日 05:18, Ton Ngo wrote:


Hi Mars,
Your paste shows that the docker service is not starting, and all the 
following services like swarm-agent fails because of the dependency. 
The error message INVALIDARGUMENT seems odd, I have seen elsewhere but 
not with docker. If you log into the node, you can check the docker 
command itself, like:

docker --help
Or manually run the full command as done in the service:
/usr/bin/docker -d -H fd:// -H tcp://0.0.0.0:2375 --tlsverify 
--tlscacert="/etc/docker/ca.crt" --tlskey="/etc/docker/server.key" 
--tlscert="/etc/docker/server.crt" --selinux-enabled --storage-driver 
devicemapper --storage-opt dm.fs=xfs --storage-opt 
dm.datadev=/dev/mapper/atomicos-docker--data --storage-opt 
dm.metadatadev=/dev/mapper/atomicos-docker--meta


Ton,

Inactive hide details for Hongbin Lu ---10/16/2015 01:05:12 PM---Hi 
Mars, I cannot reproduce the error. My best guess is that yHongbin Lu 
---10/16/2015 01:05:12 PM---Hi Mars, I cannot reproduce the error. My 
best guess is that your VMs don’t have external internet a


From: Hongbin Lu 
To: "OpenStack Development Mailing List (not for usage questions)" 


Date: 10/16/2015 01:05 PM
Subject: Re: [openstack-dev] [magnum] Failed to create swarm bay with 
fedora-21-atomic-5-d181.qcow2






Hi Mars,

I cannot reproduce the error. My best guess is that your VMs don’t 
have external internet access (Could you verify it by ssh into one of 
your VM and type “curl openstack.org” ?). If not, please create a bug 
to report the error (_https://bugs.launchpad.net/magnum_).


Thanks,
Hongbin

*From:*Mars Ma [mailto:wenc...@gmail.com] *
Sent:*October-16-15 2:37 AM*
To:*openstack-dev@lists.openstack.org*
Subject:*[openstack-dev] [magnum] Failed to create swarm bay with 
fedora-21-atomic-5-d181.qcow2


Hi,

I used image fedora-21-atomic-5-d181.qcow2 to create swarm bay , but 
the bay went to failed status with status reason: Resource CREATE 
failed: WaitConditionFailure: 
resources.swarm_nodes.resources[0].resources.node_agent_wait_condition: swarm-agent 
service failed to start.
debug inside swarm node, found that docker failed to start, lead to 
swarm-agent and swarm-manager services failed to start.
[fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ 
docker -v

Docker version 1.8.1.fc21, build 32b8b25/1.8.1

detailed debug log, I pasted here :
_http://paste.openstack.org/show/476450/_




Thanks & Best regards !
Mars 
Ma__

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


--
BR, Eli(Li Yong)Qiao

<>__
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] How to call 3rd-party tools(such as Ansible) in Mistral

[WANG, Ming Hao (Tony T)]

Renat,

Thanks for your valuable comments. ☺
The “custom action” needs to re-install Mistral.
If the Mistral service is part of 3rd party OpenStack, it may be unacceptable 
to let every user create his own customer action. What do you think?

Thanks,
Tony


From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
Sent: Saturday, October 17, 2015 3:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as 
Ansible) in Mistral

Hi, see my answers inline.

On 16 Oct 2015, at 12:35, WANG, Ming Hao (Tony T) 
mailto:tony.a.w...@alcatel-lucent.com>> wrote:

We have developed some Ansible playbooks for operation automation, and we are 
investigating if we can change the automation engine from Ansible to Mistral 
since Mistral has powerful workflow control.
Could you please help to provide how to let Mistral call Ansible playbook or 
Ansible module?

I would recommend to write a custom action (not ad-hoc actions in DSL, they are 
pretty limited). You can just write a python class and make it available in 
Mistral workflow. It is pretty easy to do and described at [1]. In Python 
you’ll have more control on how to call ansible properly. If you have any 
specific questions on that you can join our IRC channel #openstack-mistral and 
talk to us there.


My understanding is to use ssh std_action to let Mistral access Ansible server 
to call Ansible playbook/modules since Mistral ad-hoc action must base on an 
existing system action.

Yes, you can use std.ssh action but I guess it won’t be too convenient because 
you’ll have to deal with shell commands directly. Yes, ad-hoc actions can help 
you do it in a more elegant manner but they are pretty limited and allow to 
create only wrappers. With Python custom actions (it can be a class hierarchy, 
for example) you can do much more. For instance, you can expose individual 
ansible actions and transform their params in a form that better fits workflow 
DSL.

Anyway, it’s just my preference. You may like this second option better.


Another question is:
If we install Mistral and Ansible on a same server, is it possible to simplify 
it?

Yes, like I described above.

[1] 
http://docs.openstack.org/developer/mistral/developer/creating_custom_action.html


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] [Neutron] [Tempest] where fwaas tempest tests should be?

[Takashi Yamamoto]

hi,

On Sat, Oct 17, 2015 at 12:50 AM, Eichberger, German
 wrote:
> Hi,
>
> Just moving the tests is not sufficient since the gate jobs also need
> adjustment.

yea.
do yo have any advice how it should be done?
i submitted an experimental job [2] so that the movement can be tested at least.
how do you think?

[2] https://review.openstack.org/#/c/236762/

>
> German
>
> On 10/16/15, 1:50 AM, "Takashi Yamamoto"  wrote:
>
>>hi,
>>
>>On Thu, Oct 15, 2015 at 11:17 PM, Matthew Treinish 
>>wrote:
>>> On Thu, Oct 15, 2015 at 08:25:40PM +0900, Takashi Yamamoto wrote:
 hi,

 i'm looking in fwaas tempest tests and have a question about code
location.

 currently,

 - fwaas api tests and its rest client are in neutron repo
>>>
>>> This is a bad situation because it means that we're directly coupling
>>>fwaas to
>>> the neutron repo. Everything that depends on fwaas should be separate
>>>and self
>>> contained outside of the neutron repo. The longer that things are like
>>>this it
>>> will just lead to more headaches down the road.
>>>
 - there are no fwaas scenario tests

 eventually,

 - fwaas api tests should be moved into neutron-fwaas repo
 - fwaaa scenario tests should be in neutron-fwaas repo too.
>>>
>>> This is definitely the right direction.
>>
>>if i move fwaas tests from neutron to neutron-fwaas, [1]
>>is there easy way to run them together with the rest of neutron api tests
>>for gate-neutron-dsvm-api job?
>>
>>[1] https://review.openstack.org/#/c/235790/
>>
>>>
 - the rest client will be in tempest-lib
>>>
>>> The discussion on which clients are in scope for tempest-lib hasn't
>>>fully
>>> happened yet. For right now we're taking a conservative approach and
>>>the clients
>>> can live in tempest-lib if there are tests in the tempest tree using
>>>them.
>>> (which is not fwaas) This might change eventually, (there will be a
>>>summit
>>> session on it) but for right now I'd say the fwaas clients should live
>>>in the
>>> fwaas repo. (they can and likely should still be based on the
>>>tempest-lib rest
>>> client)
>>>
>>> -Matt Treinish
>>>
>>>
>>>_
>>>_
>>> 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 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] How to call 3rd-party tools(such as Ansible) in Mistral

[WANG, Ming Hao (Tony T)]

Dmitri,

Thanks for your valuable info. :)
I suppose  the flow here should be:
Mistral calls StackStorm, and StackStorm calls Ansible. Is it right?
The big benefit here should be we only need to install StackStorm custom action 
into Mistral, and StackStorm will handle all the interfaces to other automation 
tools, such as Ansible. Is it right?

Thanks,
Tony

From: Dmitri Zimine [mailto:dzim...@stackstorm.com]
Sent: Sunday, October 18, 2015 1:27 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as 
Ansible) in Mistral

Tony,

You can also connect Mistral with Ansible via StackStorm and Ansible 
integration pack:
1) StackStorm http://docs.stackstorm.com
2) https://github.com/StackStorm/st2contrib/tree/master/packs/ansible

StackStorm is open-source Apache 2.0 "wrapper" around Mistral workflow service 
that integrates 3rd party tools.

Disclosure: I work for StackStorm, I think it's appropriate to pitch here an 
open source project that addresses the problem.

DZ.


On Oct 15, 2015, at 11:35 PM, WANG, Ming Hao (Tony T) 
mailto:tony.a.w...@alcatel-lucent.com>> wrote:


Dear Mistral developers and testers,

We have developed some Ansible playbooks for operation automation, and we are 
investigating if we can change the automation engine from Ansible to Mistral 
since Mistral has powerful workflow control.
Could you please help to provide how to let Mistral call Ansible playbook or 
Ansible module?
My understanding is to use ssh std_action to let Mistral access Ansible server 
to call Ansible playbook/modules since Mistral ad-hoc action must base on an 
existing system action.

Another question is:
If we install Mistral and Ansible on a same server, is it possible to simplify 
it?

Thanks in advance,
Tony

__
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] Failed to create swarm bay with fedora-21-atomic-5-d181.qcow2

[Mars Ma]

Hi Hongbin,

I can ssh into the swarm node, and curl cmd works ok:
[fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ curl
openstack.org

301 Moved Permanently

301 Moved Permanently
nginx



On Fri, Oct 16, 2015 at 2:36 PM, Mars Ma  wrote:

> Hi,
>
> I used image fedora-21-atomic-5-d181.qcow2 to create swarm bay , but the
> bay went to failed status with status reason: Resource CREATE failed:
> WaitConditionFailure:
> resources.swarm_nodes.resources[0].resources.node_agent_wait_condition:
> swarm-agent service failed to start.
> debug inside swarm node, found that docker failed to start, lead to
> swarm-agent and swarm-manager services failed to start.
> [fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ docker
> -v
> Docker version 1.8.1.fc21, build 32b8b25/1.8.1
>
> detailed debug log, I pasted here :
> http://paste.openstack.org/show/476450/
>
>
>
>
> Thanks & Best regards !
> Mars Ma
>
__
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] [Zaqar] Design Summit Schedule

[Flavio Percoco]

On 19/10/15 05:26 +1300, Fei Long Wang wrote:

Hi everyone,

I just posted the Zaqar schedule for design summit:

https://mitakadesignsummit.sched.org/overview/type/zaqar

Please let me know if there is any schedule conflicts for you, so we can work 
out it on next weekly meeting.

Session Leaders: Please fill the etherpad on 
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Zaqar Thanks.


The session I'm leading doesn't conflict, others do but that's going
to be really hard to avoid.

LGTM, thanks!
Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [magnum] Failed to create swarm bay with fedora-21-atomic-5-d181.qcow2

[Mars Ma]

Hi Ton,

"docker --help" command works ok, but
[fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ sudo
/usr/bin/docker -d -H fd:// -H tcp://0.0.0.0:2375 --tlsverify
--tlscacert="/etc/docker/ca.crt" --tlskey="/etc/docker/server.key"
--tlscert="/etc/docker/server.crt" --selinux-enabled --storage-driver
devicemapper --storage-opt dm.fs=xfs --storage-opt
dm.datadev=/dev/mapper/atomicos-docker--data --storage-opt
dm.metadatadev=/dev/mapper/atomicos-docker--meta
Warning: '-d' is deprecated, it will be removed soon. See usage.
WARN[] please use 'docker daemon' instead.
ERRO[] ServeAPI error: No sockets found
WARN[0001] --storage-opt dm.thinpooldev is preferred over --storage-opt
dm.datadev or dm.metadatadev

[fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ sudo
/usr/bin/docker daemon -H fd:// -H tcp://0.0.0.0:2375 --tlsverify
--tlscacert="/etc/docker/ca.crt" --tlskey="/etc/docker/server.key"
--tlscert="/etc/docker/server.crt" --selinux-enabled --storage-driver
devicemapper --storage-opt dm.fs=xfs --storage-opt
dm.thinpooldev=/dev/mapper/atomicos-docker--data --storage-opt
dm.metadatadev=/dev/mapper/atomicos-docker--meta
ERRO[] ServeAPI error: No sockets found
FATA[0001] Error starting daemon: error initializing graphdriver: EOF

[fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ sudo
systemctl status docker.socket
● docker.socket - Docker Socket for the API
   Loaded: loaded (/etc/systemd/system/docker.socket; enabled)
   Active: active (listening) since Fri 2015-10-16 05:55:04 UTC; 2 days ago
   Listen: /var/run/docker.sock (Stream)

Oct 16 05:55:04
sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7.novalocal systemd[1]:
Listening on Docker Socket for the API.

this is strange, log into the swarm node, cannot also start the docker
service manually.


Thanks & Best regards !
Mars Ma

On Mon, Oct 19, 2015 at 1:11 PM, Mars Ma  wrote:

> Hi Hongbin,
>
> I can ssh into the swarm node, and curl cmd works ok:
> [fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ curl
> openstack.org
> 
> 301 Moved Permanently
> 
> 301 Moved Permanently
> nginx
> 
> 
>
> On Fri, Oct 16, 2015 at 2:36 PM, Mars Ma  wrote:
>
>> Hi,
>>
>> I used image fedora-21-atomic-5-d181.qcow2 to create swarm bay , but the
>> bay went to failed status with status reason: Resource CREATE failed:
>> WaitConditionFailure:
>> resources.swarm_nodes.resources[0].resources.node_agent_wait_condition:
>> swarm-agent service failed to start.
>> debug inside swarm node, found that docker failed to start, lead to
>> swarm-agent and swarm-manager services failed to start.
>> [fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ docker
>> -v
>> Docker version 1.8.1.fc21, build 32b8b25/1.8.1
>>
>> detailed debug log, I pasted here :
>> http://paste.openstack.org/show/476450/
>>
>>
>>
>>
>> Thanks & Best regards !
>> Mars Ma
>>
>
>
__
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] [Ironic] Driver documentation in Ironic

[Wan-yen Hsu]

 I fully agreed with Ramesh.  There is a need for driver owners to be able
to quickly update their driver’s document.  Particularly, vendor's drivers
have strong dependencies on their platform’s firmware.  For instance, a new
release of firmware may have impact on vendor’s driver and may require a
specific firmware settings or some workaround in driver configuration.
Therefore driver owners need to be able to update their driver documents to
reflect support of firmware versions or hardware platforms, document
firmware issues that have impacts to the drivers, …etc.   Also, as more and
more features added to the drivers and some features are related, sometimes
it requires restructuring of the document to make it easier for readers to
follow and understand.  I would very much like to get tech writers to help
my driver’s document but with current document review process and release
schedule, it’s just very hard to do.  As the result, document quality
suffers.  I really wish that we can give driver owner’s more control of
their documents and be able to update their driver documents when needed.



 Among all 3 options listed below, I prefer 2 or 3. Please consider these
options.



 Thanks!



>The following are the options that I can think of to address this:



>1) Easy approvals for patches solely related to driver documentation. Once

>the driver team feels the documentation is ready, it can be +Aed by a core

>team member skipping the normal process of review. Of course, fixing any

>comments that come by, but not waiting for the normal rule of 2x+2s.



>2) A separate repository for driver documentation controller by driver

>developers (a bad idea ??)



>3) Allow to push driver documentation to wiki for those who wish to.



>Thoughts ???



>[0] https://review.openstack.org/#/c/225602/
__
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] [app-catalog] [glance] [murano] Data Assets API for App Catalog

[Flavio Percoco]

On 16/10/15 12:07 -0700, Christopher Aedo wrote:

On Thu, Oct 15, 2015 at 3:04 AM, Alexander Tivelkov
 wrote:

Hi folks,

I’ve noticed that the Community Application Catalog has begun to implement
its own API, and it seems to me that we are going to have some significant
duplication of efforts with the code which has already been implemented in
Glance as Artifact Repository initiative (also known as Glance V3).
From the very beginning of the App Catalog project (and I’ve been involved
in it since February) I’ve been proposing to use Glance as its backend,
because from my point of view it covers like 90% of the needed
functionality. But it looks like we have some kind of miscommunication here,
as I am getting some confusing questions and assumptions, like the vision of
Glance V3 being dedicated backend for Murano (which is definitely
incorrect).
So, I am writing the email to clarify my vision of what Glance V3 is and how
its features may be used to provide the REST API for Community App Catalog.

1.  Versioned schema
First of all, Glance V3 operates on entities called “artifacts”, and these
ones perfectly map to the Data Assets of community app catalog. The
artifacts are strongly typed: there are artifact types for murano packages,
glance images, heat templates - and there may be (and will be) more. Each
artifact type is represented by a plugin, defining the schema of objects’
data and metadata and - optionally - custom logic. So, this thing is
extensible: when a new type of asset needs to be added to a catalog it can
be done really quickly by just defining the schema and putting that schema
into a plugin. Also, these plugins are versioned, so the possible changes in
the schema are handled properly.

2. Generic properties
Next, all the artifact types in Glance V3 have some generic metadata
properties (i.e. part of the schema which is common for all the types),
including the name, the version, description, authorship information and so
on. This also corresponds to the data schema of community app catalog. The
mapping is not 1:1, but we can work together on this to make sure that these
generic properties match the expectations of the catalog.

3. Versioning
Versions are very important for catalogs of objects, so Glance V3 was
initially designed keeping versioning questions in mind: each artifact has a
semver-based version assigned, so the artifacts having the same name but
different versions are grouped into the proper sequences. API is able to
query artifacts based on their version spec, e.g. it is possible to fetch
the latest artifact with the name “foo” having the version greater than 2.1
and less than 3.5.7 - or any other version spec, similar to pip or any other
similar tool. As far as I know, community app catalog does not have such
capabilities right now - and I strongly believe that it is really a must
have feature for a catalog to be successful. At least it is absolutely
mandatory for Murano packages, which are the only “real apps” among the
asset types right now.

4. Cross artifact dependencies
Glance V3 also has the dependency relations from the very beginning, so they
may be defined as part of artifact type schema. As a result, an artifact may
“reference” any number of other artifacts with various semantic. For
example, murano package may define a set of references to other murano
packages and call it “requires” - and this will act similar to the
requirements of a python package. Similar properties may be defined for heat
templates and glance images - they may reference each other with various
semantics.
Of course, the definitions of such dependencies may be done internally
inside the packages, so they may be resolved locally by the service which is
going to use it, but letting the catalog know about them will allow us to do
the import-export operations for any given artifacts and its dependencies
automatically, only by the means of the catalog itself.

5. Search and filtering API
Right now Glance V3 API is in experimental state (we plan to stabilize it
during the Mitaka cycle), but it already provides quite good capabilities to
discover things. It can search artifacts by their type, name and
(optionally) aforementioned version specs, by tag or even by arbitrary set
of metadata properties. We have plans to integrate Glance V3 with the
Searchlight project to have even more index and search capabilities using
its elastic search engine.

6. Data storage
As you probably know, Glance does not own the binary data of its images.
Instead, it provides an abstraction of the backend storage, which may be
swift, ceph, s3 or something else. The same approach is used in Glance V3
for artifacts data, but with more per-type control: particular artifact
types may be configured independently to store their blobs in different
backends. This may be of use for Community App Catalog which operates on
different storages for its assets.

7. Sharing and access control.
Glance V3 inherits the same access mechanics present

Re: [openstack-dev] [Neutron] [Tempest] where fwaas tempest tests should be?

[Takashi Yamamoto]

hi,

On Thu, Oct 15, 2015 at 11:22 PM, Matthew Treinish  wrote:
> On Thu, Oct 15, 2015 at 09:02:22AM -0400, Assaf Muller wrote:
>> On Thu, Oct 15, 2015 at 7:25 AM, Takashi Yamamoto 
>> wrote:
>>
>> > hi,
>> >
>> > i'm looking in fwaas tempest tests and have a question about code location.
>> >
>> > currently,
>> >
>> > - fwaas api tests and its rest client are in neutron repo
>> > - there are no fwaas scenario tests
>> >
>> > eventually,
>> >
>> > - fwaas api tests should be moved into neutron-fwaas repo
>> > - fwaaa scenario tests should be in neutron-fwaas repo too.
>> >
>>
>> I believe scenario tests that invoke APIs outside of Neutron should
>> stay (Or be introduced to) Tempest.
>
> So testing the neutron advanced services was actually one of the first things
> we decided was out of scope for tempest. (like well over a year ago) It took
> some time to get equivalent testing setup elsewhere, but tests and support for
> the advanced services were removed from tempest on purpose. I'd suggest that
> you look at the tempest plugin interface:
>
> http://docs.openstack.org/developer/tempest/plugin.html
>
> if you'd like to make the fwaas tests (or any other adv. service tests)
> integrate more cleanly with the rest of tempest.

is there a clean way for a plugin to extend NetworkClientJSON for fwaas?

>
> -Matt Treinish
>
> __
> 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] [app-catalog] [glance] [murano] Data Assets API for App Catalog

[Flavio Percoco]

On 16/10/15 16:44 +, Fox, Kevin M wrote:

I agree that there’s a lot more room for cross project communication here at
very least. I was really hoping that we could get representatives from the
glance artifact subproject, the app-catalog, and the Murano teams in a room at
the summit and hash out some of this and other things. There is some overlap
and ambiguity that would be great to iron out if we could.



I think there’s too much to discuss to do it via email, but I’ll take a stab at
a few things here.



We’ve been waiting for 6 months for a POC for what you describe below and kind
of gave up on it. We needed to ship something and couldn’t wait any more. If
you think your close enough that you can show us at the summit, that would be
great. We’d be very happy to see it.


I'm sorry to ask but I really don't know.

Was this a silent wait? Or did you guys actively showed interest and
asked for the POC?

I'd like to understand how this has escalated and see how we can do
better. Especially in the best interest of de-duplicating efforts.


At present, here’s my thinking about some of the things listed below:



I think sharing the schema at very least would be great. If the versioning
stuff you have covers everything the app-catalog needs, we should just use it
rather then coming up with something ourselves. If its not set in stone right
now, it’s an ideal time to ensure all the features needed are there.



The root of the tree, as you describe it has some problems that the rest of the
tree doesn’t. Its global and unauthenticated. It has to be Internet scale, not
just single cloud scale. Like you said, glance supports features for
authorization. But those may be anti-features for the root that may cause
excessive overhead when used as a root, unauthenticated source. The same is
true of Searchlight. Searchlight buys you elasticsearch+authorization/
multitenancy, which the root catalog’s don’t need. They just need
eleasticsearch, so Searchlight may add complexity without any benefit. Don’t
get me wrong. I think Searchlight is awesome, just maybe not for https://
apps.openstack.org.



Not saying any of that is true, just possible reasons why we may not want to
use glance’s implementation at the root. We have to carefully consider things.



If that code base can’t be shared, what may make more sense (I’m not sure. Just
laying options out), is to share a glance v3 artifact compatible api that
glance can point at for the root? Or a subset of the v3 api that makes sense to
both use cases and still supports the tree hierarchy.



Like you said, we may need to extend the api specification to support some of
the features that are unique to the app-catalog use cases too. If you’re open
to it, I think we are too. If we go the route of sharing an api but not a
server implementation, that may not be necessary though.



Anyway, thanks for starting the conversation. I think it’s a great thing to get
going. Can we get together at the summit and discuss further?


++

Thanks for chiming in, Kevin
Flavio





Thanks,

Kevin





From: Alexander Tivelkov [mailto:ativel...@mirantis.com]
Sent: Thursday, October 15, 2015 3:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [app-catalog] [glance] [murano] Data Assets API for
App Catalog



Hi folks,



I’ve noticed that the Community Application Catalog has begun to implement its
own API, and it seems to me that we are going to have some significant
duplication of efforts with the code which has already been implemented in
Glance as Artifact Repository initiative (also known as Glance V3).

From the very beginning of the App Catalog project (and I’ve been involved in
it since February) I’ve been proposing to use Glance as its backend, because
from my point of view it covers like 90% of the needed functionality. But it
looks like we have some kind of miscommunication here, as I am getting some
confusing questions and assumptions, like the vision of Glance V3 being
dedicated backend for Murano (which is definitely incorrect).

So, I am writing the email to clarify my vision of what Glance V3 is and how
its features may be used to provide the REST API for Community App Catalog.



1.  Versioned schema

First of all, Glance V3 operates on entities called “artifacts”, and these ones
perfectly map to the Data Assets of community app catalog. The artifacts are
strongly typed: there are artifact types for murano packages, glance images,
heat templates - and there may be (and will be) more. Each artifact type is
represented by a plugin, defining the schema of objects’ data and metadata and
- optionally - custom logic. So, this thing is extensible: when a new type of
asset needs to be added to a catalog it can be done really quickly by just
defining the schema and putting that schema into a plugin. Also, these plugins
are versioned, so the possible changes in the schema are handled properly. 




2. Generic properties

Next, all the art