[openstack-dev] Role in Congress

[zhangyali (D)]

Hi Tim and All,

I remember there is a topic named "role assignment for service users" in the 
Tokyo Summit. Since I have not heard any message of this topic. Does anyone 
could contribute some information for me? I think it is vital for my design of 
Congress UI in horizon. Thanks a lot!

Best Regards,
Yali

__
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] [release] using reno for libraries

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2015-11-27 10:21:36 -0500:
> Liaisons,
> 
> We're making good progress on adding reno to service projects as
> we head to the Mitaka-1 milestone. Thank you!
> 
> We also need to add reno to all of the other deliverables with
> changes that might affect deployers. That means clients and other
> libraries, SDKs, etc. with configuration options or where releases
> can change deployment behavior in some way. Now that most teams
> have been through this conversion once, it should be easy to replicate
> for the other repositories in a similar way.
> 
> Libraries have 2 audiences for release notes: developers consuming
> the library and deployers pushing out new versions of the libraries.
> To separate the notes for the two audiences, and avoid doing manually
> something that we have been doing automatically, we can use reno
> just for deployer release notes (changes in support for options,
> drivers, etc.). That means the library repositories that need reno
> should have it configured just like for the service projects, with
> the separate jobs and a publishing location different from their
> existing developer documentation. The developer docs can continue
> to include notes for the developer audience.

I've had a couple of questions about this split for release notes. The
intent is for developer-focused notes to continue to come from commit
messages and in-tree documentation, while using reno for new and
additional deployer-focused communication. Most commits to libraries
won't need reno release notes.

Doug

> 
> After we start using reno for libraries, the release announcement
> email tool will be updated to use those same notes to build the
> message in addition to looking at the git change log. This will be
> a big step toward unifying the release process for services and
> libraries, and will allow us to make progress on completing the
> automation work we have planned for this cycle.
> 
> It's not necessary to add reno to the liberty branch for library
> projects, since we tend to backport far fewer changes to libraries.
> If you maintain a library that does see a lot of backports, by all
> means go ahead and add reno, but it's not a requirement. If you do
> set up multiple branches, make sure you have one page that uses the
> release-notes directive without specifing a branch, as in the
> oslo.config example, to build notes for the "current" branch to get
> releases from master and to serve as a test for rendering notes
> added to stable branches.
> 
> Thanks,
> Doug
> 

__
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] [oslo] Proposal for new core reviewer: ChangBo Guo

[Doug Hellmann]

Excerpts from Victor Stinner's message of 2015-11-27 17:23:05 +0100:
> Hi,
> 
> I noticed that ChangBo Guo (aka gcb) is very active in various Oslo 
> projects, to write patches but also to review patches written by others. 
> He attend Oslo meetings, welcome reviews, etc. It's a pleasure to work 
> with him.
> 
> To accelerate the Oslo development, I propose to invite ChangBo to 
> become an Oslo core reviewer. I asked him privately and he already 
> replied that it would be a honor for him.
> 
> What do you think?
> 
> ChangBo Guo's open changes:
> 
> https://review.openstack.org/#/q/owner:glongw...@gmail.com+status:open,n,z
> 
> ChangBo Guo's merged changes:
> 
> https://review.openstack.org/#/q/owner:glongw...@gmail.com+status:merged,n,z
> 
> Victor
> 

+1 for adding gcb

And thanks to Victor for recognizing a valuable contributor as a
potential core team member.

Doug

__
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] Using docker container to run COE daemons

[Daneyon Hansen (danehans)]

From: Jay Lau >
Reply-To: OpenStack Development Mailing List 
>
Date: Wednesday, November 25, 2015 at 3:15 PM
To: OpenStack Development Mailing List 
>
Subject: [openstack-dev] [magnum] Using docker container to run COE daemons

Hi,

It is becoming more and more popular to use docker container run some 
applications, so what about leveraging this in Magnum?


What I want to do is that we can put all COE daemons running in docker 
containers, because now Kubernetes, Mesos and Swarm support running in docker 
container and there are already some existing docker images/dockerfiles which 
we can leverage.

Jay,

It is my understanding that we have blueprints to address this topic:

https://blueprints.launchpad.net/magnum/+spec/run-kube-as-container
https://blueprints.launchpad.net/magnum/+spec/mesos-in-container

In addition to the COE daemons, the run-kube-as-a-container blueprint will 
address additional processes such as etcd and flannel. Swarm-agent/manager is 
already running as containers.


So what about update all COE templates to use docker container to run COE 
daemons and maintain some dockerfiles for different COEs in Magnum? This can 
reduce the maintain effort for COE as if there are new versions and we want to 
upgrade, just update the dockerfile is enough. Comments?

I would expect the templates to be updated as part of the blueprints above. As 
with the swarm template, I believe each coe service would correlate to a 
systemd unit file that specifies a docker pull/run of a specific image.


--
Thanks,

Jay Lau (Guangya Liu)
__
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]How to use Murano to transmit files to Mistral and execute scripts on Mistral

[Stan Lagun]

Hi Tony,

Technically your solution is possible. Murano agent can be installed
manually. All queue names are in agent's config file. Murano can talk to
that manually installed agent and put files to that server.

However I strongly advice not to do that. First of all it is not secure.
Murano agent was designed as a remote execution mechanism rather than a
tool to transfer files. Also it was design to be installed on VM
rather that on a shared server. Currently there is no authentication for
agents. Although it is not truly secure it still provides significant level
of security because to make use of the agent you need to know its queue name
which is a long random string that only murano engine and agent know and
AMQP doesn't provide an API to query list of queue names. But if you
install agent manually there will be a single queue. And all applications
that
need to access that agent will also need to know queue name. Thus it can be
easily be compromised and attackers will gain ability to execute arbitrary
code on the nova server.

It is also doesn't seem like a right solution. There should not be such
specific requirements like this to perform such trivial thing. Especially
if it involves using tool that was design for something else.

So what is the right solution?

I can see 2 possible ways to address this issue:

1. Improve Mistral API to support file attachments to its workbooks (if it
doesn't support it yet). Improve murano-mistral integration to support this
feature.
2. Implement integration of Murano with object storage. Thus it will be
possible from Murano workflow to upload file and provide Mistral with a URI
to it.

Solution #2 seem to be better. At least because it opens new possibilities
for all applications and not just those that use Mistral.

There is also a workaround that I can think of: make Murano application
create temporary VM with FTP server or something like that, put file into
it and give Mistral a URI it could use to access the file.

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis



On Wed, Nov 18, 2015 at 1:06 PM, WANG, Ming Hao (Tony T) <
tony.a.w...@alcatel-lucent.com> wrote:

> Dear Alexander and Murano developers and testers,
>
>
>
> Any suggestion for this? J
>
>
>
> Thanks,
>
> Tony
>
>
>
> *From:* WANG, Ming Hao (Tony T)
> *Sent:* Tuesday, November 17, 2015 6:12 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* RE: [openstack-dev] [murano]How to use Murano to transmit
> files to Mistral and execute scripts on Mistral
>
>
>
> Alexander,
>
>
>
> Thanks for your response.
>
> During the workflow running stage, it may need to access some other
> artifacts.
>
> In my case, I use Mistral workflow to call Ansible playbook, and I need
> Murano to put Ansible playbook into right place on Mistral server so that
> Mistral workflow can find it.
>
>
>
> Thanks,
>
> Tony
>
>
>
> *From:* Alexander Tivelkov [mailto:ativel...@mirantis.com
> ]
> *Sent:* Tuesday, November 17, 2015 4:19 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [murano]How to use Murano to transmit
> files to Mistral and execute scripts on Mistral
>
>
>
> Hi Tony,
>
>
>
> Probably I am missing something, but why do you need Murano Agent to
> interact with Mistral? You can call Mistral APIs right from MuranoPL code
> being executed by Murano Engine. Murano's core library contains the 
> io.murano.system.MistralClient
> class ([1]) which may be used to upload and run mistral workflows.
>
>
>
> Please let me know if you need more details on this
>
>
>
> [1]
> https://github.com/openstack/murano/blob/master/murano/engine/system/mistralclient.py
>
>
>
> On Tue, Nov 17, 2015 at 5:07 AM WANG, Ming Hao (Tony T) <
> tony.a.w...@alcatel-lucent.com> wrote:
>
> Dear Murano developers and testers,
>
>
>
> I want to put some files that Mistral workflow needs into Murano package,
> and hope Murano can transmit them to Mistral before it calls Mistral
> workflow.
>
> The flow should be as following:
>
> 1.   User uploads one Murano package which includes both
> Murano artifacts and Mistral artifacts to Murano;
>
> 2.   Murano transmits the Mistral artifacts to Mistral,
> and Mistral does its work.
>
>
>
> After study, I thought muranoagent may be helpful and plan to install a
> muranoagent on the Mistral server since it can put files into nova server,
> and can run scripts on the nova server.
>
> After further study, I found muranoagent solution may be not feasible:
>
> 1.   muranoagent and murano-engine(dsl) uses rabbitMQ to
> communicate.
>
> 2.   When an Agent object is created in DSL,
> murano-engine creates a unique message queue to communicate with the
> muranoagent in nova instance:
>
> The queue name consists of current murano environment id, and the nova
> instance murano object id.
>
> 3.   

[openstack-dev] [neutron][L3][DVR][arp]

[Wuhongning]

Is it a good idea to add a configuration item for dvr, to disable any arp entry 
processing, and reuse arp response from L2population?

When no static arp entry is found in qrouter namespace, it would cause a temp 
arp request, then it reached the br-tun, and replied by the OVS flow table.

In a public cloud like AWS, it allow 200 subnets for each vpc, so sync routes 
would waste a lot of time
__
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