Hi,Fox Kevin M

Thanks for your help.
Also,I want to know whether these features will be implemented in Ironic?
Do we have a plan to implement them?

Thanks
Xianchaobo



-----邮件原件-----
发件人: openstack-dev-requ...@lists.openstack.org 
[mailto:openstack-dev-requ...@lists.openstack.org] 
发送时间: 2014年12月9日 18:36
收件人: openstack-dev@lists.openstack.org
主题: OpenStack-dev Digest, Vol 32, Issue 25

Send OpenStack-dev mailing list submissions to
        openstack-dev@lists.openstack.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
        openstack-dev-requ...@lists.openstack.org

You can reach the person managing the list at
        openstack-dev-ow...@lists.openstack.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."


Today's Topics:

   1.  [Mistral] Query on creating multiple resources (Sushma Korati)
   2. Re: [neutron] Changes to the core team
      (trinath.soman...@freescale.com)
   3. [Neutron][OVS] ovs-ofctl-to-python blueprint (YAMAMOTO Takashi)
   4. Re: [api] Using query string or request body to   pass
      parameter (Alex Xu)
   5. [Ironic] Some questions about Ironic service (xianchaobo)
   6. [Ironic] How to get past pxelinux.0 bootloader? (Peeyush Gupta)
   7. Re: [neutron] Changes to the core team (Gariganti, Sudhakar Babu)
   8. Re: [neutron][lbaas] Shared Objects in LBaaS - Use Cases that
      led us to adopt this. (Samuel Bercovici)
   9. [Mistral] Action context passed to all action     executions by
      default (W Chan)
  10. Cross-Project meeting, Tue December 9th, 21:00 UTC
      (Thierry Carrez)
  11. Re: [Mistral] Query on creating multiple resources
      (Renat Akhmerov)
  12. Re: [Mistral] Query on creating multiple resources
      (Renat Akhmerov)
  13. Re: [Mistral] Event Subscription (Renat Akhmerov)
  14. Re: [Mistral] Action context passed to all action executions
      by default (Renat Akhmerov)
  15. Re: Cross-Project meeting, Tue December 9th, 21:00 UTC (joehuang)
  16. Re: [Ironic] Some questions about Ironic service (Fox, Kevin M)
  17. [Nova][Neutron] out-of-tree plugin for Mech       driver/L2 and
      vif_driver (Maxime Leroy)
  18. Re: [Ironic] How to get past pxelinux.0 bootloader? (Fox, Kevin M)
  19. Re: [Ironic] Fuel agent proposal (Roman Prykhodchenko)
  20. Re: [Ironic] How to get past pxelinux.0 bootloader?
      (Peeyush Gupta)
  21. Re: Cross-Project meeting, Tue December 9th, 21:00 UTC
      (Thierry Carrez)
  22.  [neutron] mid-cycle "hot reviews" (Miguel ?ngel Ajo)
  23. Re: [horizon] REST and Django (Tihomir Trifonov)


----------------------------------------------------------------------

Message: 1
Date: Tue, 9 Dec 2014 05:57:35 +0000
From: Sushma Korati <sushma_kor...@persistent.com>
To: "gokrokvertsk...@mirantis.com" <gokrokvertsk...@mirantis.com>,
        "zbit...@redhat.com" <zbit...@redhat.com>
Cc: "openstack-dev@lists.openstack.org"
        <openstack-dev@lists.openstack.org>
Subject: [openstack-dev]  [Mistral] Query on creating multiple
        resources
Message-ID: <1418105060569.62...@persistent.com>
Content-Type: text/plain; charset="iso-8859-1"


Hi,


Thank you guys.


Yes I am able to do this with heat, but I faced issues while trying the same 
with mistral.

As suggested will try with the latest mistral branch. Thank you once again.


Regards,

Sushma


________________________________


From: Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com]
Sent: Tuesday, December 09, 2014 6:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Mistral] Query on creating multiple resources

Hi Sushma,

Did you explore Heat templates? As Zane mentioned you can do this via Heat 
template without writing any workflows.
Do you have any specific use cases which you can't solve with Heat template?

Create VM workflow was a demo example. Mistral potentially can be used by Heat 
or other orchestration tools to do actual interaction with API, but for user it 
might be easier to use Heat functionality.

Thanks,
Georgy

On Mon, Dec 8, 2014 at 7:54 AM, Nikolay Makhotkin 
<nmakhot...@mirantis.com<mailto:nmakhot...@mirantis.com>> wrote:
Hi, Sushma!
Can we create multiple resources using a single task, like multiple keypairs or 
security-groups or networks etc?

Yes, we can. This feature is in the development now and it is considered as 
experimental - 
https://blueprints.launchpad.net/mistral/+spec/mistral-dataflow-collections

Just clone the last master branch from mistral.

You can specify "for-each" task property and provide the array of data to your 
workflow:

 --------------------

version: '2.0'

name: secgroup_actions

workflows:
  create_security_group:
    type: direct
    input:
      - array_with_names_and_descriptions

    tasks:
      create_secgroups:

        for-each:

          data: $.array_with_names_and_descriptions
        action: nova.security_groups_create 
name={$.data.name<http://data.name>} description={$.data.description}
------------

On Mon, Dec 8, 2014 at 6:36 PM, Zane Bitter 
<zbit...@redhat.com<mailto:zbit...@redhat.com>> wrote:
On 08/12/14 09:41, Sushma Korati wrote:
Can we create multiple resources using a single task, like multiple
keypairs or security-groups or networks etc?

Define them in a Heat template and create the Heat stack as a single task.

- ZB

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best Regards,
Nikolay

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com<http://www.mirantis.com/>
Tel. +1 650 963 9828
Mob. +1 650 996 3284

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the 
property of Persistent Systems Ltd. It is intended only for the use of the 
individual or entity to which it is addressed. If you are not the intended 
recipient, you are not authorized to read, retain, copy, print, distribute or 
use this message. If you have received this communication in error, please 
notify the sender and delete all copies of this message. Persistent Systems 
Ltd. does not accept any liability for virus infected mails.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/420872fd/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 9 Dec 2014 05:57:44 +0000
From: "trinath.soman...@freescale.com"
        <trinath.soman...@freescale.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] Changes to the core team
Message-ID:
        
<bn1pr03mb153e9e8a2fb42d92649ea0897...@bn1pr03mb153.namprd03.prod.outlook.com>
        
Content-Type: text/plain; charset="utf-8"

Congratulation Kevin and Henry ?

--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048

From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: Monday, December 08, 2014 11:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Changes to the core team

On Tue, Dec 2, 2014 at 9:59 AM, Kyle Mestery 
<mest...@mestery.com<mailto:mest...@mestery.com>> wrote:
Now that we're in the thick of working hard on Kilo deliverables, I'd
like to make some changes to the neutron core team. Reviews are the
most important part of being a core reviewer, so we need to ensure
cores are doing reviews. The stats for the 180 day period [1] indicate
some changes are needed for cores who are no longer reviewing.

First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
neutron-core. Bob and Nachi have been core members for a while now.
They have contributed to Neutron over the years in reviews, code and
leading sub-teams. I'd like to thank them for all that they have done
over the years. I'd also like to propose that should they start
reviewing more going forward the core team looks to fast track them
back into neutron-core. But for now, their review stats place them
below the rest of the team for 180 days.

As part of the changes, I'd also like to propose two new members to
neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
been very active in reviews, meetings, and code for a while now. Henry
lead the DB team which fixed Neutron DB migrations during Juno. Kevin
has been actively working across all of Neutron, he's done some great
work on security fixes and stability fixes in particular. Their
comments in reviews are insightful and they have helped to onboard new
reviewers and taken the time to work with people on their patches.

Existing neutron cores, please vote +1/-1 for the addition of Henry
and Kevin to the core team.
Enough time has passed now, and Kevin and Henry have received enough +1 votes. 
So I'd like to welcome them to the core team!

Thanks,
Kyle

Thanks!
Kyle

[1] http://stackalytics.com/report/contribution/neutron-group/180

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/5258ee17/attachment-0001.html>

------------------------------

Message: 3
Date: Tue,  9 Dec 2014 14:58:04 +0900 (JST)
From: yamam...@valinux.co.jp (YAMAMOTO Takashi)
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][OVS] ovs-ofctl-to-python blueprint
Message-ID: <20141209055804.536E57094A@kuma.localdomain>
Content-Type: Text/Plain; charset=us-ascii

hi,

here's a blueprint to make OVS agent use Ryu to talk with OVS.

    https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python
    https://review.openstack.org/#/c/138980/  (kilo spec)

given that ML2/OVS is one of the most popular plugins and the proposal
has a few possible controversial points, i want to ask wider opinions.

- it introduces a new requirement for OVS agent. (Ryu)
- it makes OVS agent require newer OVS version than it currently does.
- what to do for xenapi support is still under investigation/research.
- possible security impact.

please comment on gerrit if you have any opinions.  thank you.

YAMAMOTO Takashi



------------------------------

Message: 4
Date: Tue, 9 Dec 2014 14:28:33 +0800
From: Alex Xu <sou...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [api] Using query string or request body
        to      pass parameter
Message-ID:
        <CAH7mGavuTfWON=PgDcMrg9hoNrYViO+e=fdeuesrwh26otm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Kevin, thanks for the info! I agree with you. RFC is the authority. use
payload in the DELETE isn't good way.

2014-12-09 7:58 GMT+08:00 Kevin L. Mitchell <kevin.mitch...@rackspace.com>:

> On Tue, 2014-12-09 at 07:38 +0800, Alex Xu wrote:
> > Not sure all, nova is limited
> > at
> https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi.py#L79
> > That under our control.
>
> It is, but the client frameworks aren't, and some of them prohibit
> sending a body with a DELETE request.  Further, RFC7231 has this to say
> about DELETE request bodies:
>
>         A payload within a DELETE request message has no defined semantics;
>         sending a payload body on a DELETE request might cause some
> existing
>         implementations to reject the request.
>
> (?4.3.5)
>
> I think we have to conclude that, if we need a request body, we cannot
> use the DELETE method.  We can modify the operation, such as setting a
> "force" flag, with a query parameter on the URI, but a request body
> should be considered out of bounds with respect to DELETE.
>
> > Maybe not just ask question for delete, also for other method.
> >
> > 2014-12-09 1:11 GMT+08:00 Kevin L. Mitchell <
> kevin.mitch...@rackspace.com>:
> >         On Mon, 2014-12-08 at 14:07 +0800, Eli Qiao wrote:
> >         > I wonder if we can use body in delete, currently , there isn't
> any
> >         > case used in v2/v3 api.
> >
> >         No, many frameworks raise an error if you try to include a body
> with a
> >         DELETE request.
> >         --
> >         Kevin L. Mitchell <kevin.mitch...@rackspace.com>
> >         Rackspace
>
> --
> Kevin L. Mitchell <kevin.mitch...@rackspace.com>
> Rackspace
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/0de78824/attachment-0001.html>

------------------------------

Message: 5
Date: Tue, 9 Dec 2014 06:29:50 +0000
From: xianchaobo <xiancha...@huawei.com>
To: "openstack-dev@lists.openstack.org"
        <openstack-dev@lists.openstack.org>
Cc: "Luohao \(brian\)" <brian.luo...@huawei.com>
Subject: [openstack-dev] [Ironic] Some questions about Ironic service
Message-ID:
        
<d008c043f9162e45a8153719ded7cc4b33fb9...@szxeml559-mbx.china.huawei.com>
        
Content-Type: text/plain; charset="us-ascii"

Hello, all

I'm trying to install and configure Ironic service, something confused me.
I create two neutron networks, public network and private network.
Private network is used to deploy physical machines
Public network is used to provide floating ip.


(1)     Private network type can be VLAN or VXLAN? (In install guide, the 
network type is flat)

(2)     The network of deployed physical machines can be managed by neutron?

(3)     Different tenants can have its own network to manage physical machines?

(4)     Does the ironic provide some mechanism for deployed physical machines

to use storage such as shared storage,cinder volume?

Thanks,
XianChaobo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/c752d0da/attachment-0001.html>

------------------------------

Message: 6
Date: Tue, 09 Dec 2014 12:25:39 +0530
From: Peeyush Gupta <gpeey...@linux.vnet.ibm.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Ironic] How to get past pxelinux.0
        bootloader?
Message-ID: <54869ceb.4040...@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

So, I have set up a devstack ironic setup for baremetal deployment. I
have been able to deploy a baremetal node successfully using
pxe_ipmitool driver. Now, I am trying to boot a server where I already
have a bootloader i.e. I don't need pxelinux to go and fetch kernel and
initrd images for me. I want to transfer them directly.

I checked out the code and figured out that there are dhcp opts
available, that are modified using pxe_utils.py, changing it didn't
help. Then I moved to ironic.conf, but here also I only see an option to
add pxe_bootfile_name, which is exactly what I want to avoid. Can anyone
please help me with this situation? I don't want to go through
pxelinux.0 bootloader, I just directly want to transfer kernel and
initrd images.

Thanks.

-- 
Peeyush Gupta
gpeey...@linux.vnet.ibm.com




------------------------------

Message: 7
Date: Tue, 9 Dec 2014 07:07:20 +0000
From: "Gariganti, Sudhakar Babu" <sudhakar-babu.gariga...@hp.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] Changes to the core team
Message-ID:
        <db734b7e9e26414e9e6ca4ec5ed3ac2d2446b...@g6w2498.americas.hpqcorp.net>
        
Content-Type: text/plain; charset="utf-8"

Congrats Kevin and Henry ?.

From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: Monday, December 08, 2014 11:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Changes to the core team

On Tue, Dec 2, 2014 at 9:59 AM, Kyle Mestery 
<mest...@mestery.com<mailto:mest...@mestery.com>> wrote:
Now that we're in the thick of working hard on Kilo deliverables, I'd
like to make some changes to the neutron core team. Reviews are the
most important part of being a core reviewer, so we need to ensure
cores are doing reviews. The stats for the 180 day period [1] indicate
some changes are needed for cores who are no longer reviewing.

First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
neutron-core. Bob and Nachi have been core members for a while now.
They have contributed to Neutron over the years in reviews, code and
leading sub-teams. I'd like to thank them for all that they have done
over the years. I'd also like to propose that should they start
reviewing more going forward the core team looks to fast track them
back into neutron-core. But for now, their review stats place them
below the rest of the team for 180 days.

As part of the changes, I'd also like to propose two new members to
neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
been very active in reviews, meetings, and code for a while now. Henry
lead the DB team which fixed Neutron DB migrations during Juno. Kevin
has been actively working across all of Neutron, he's done some great
work on security fixes and stability fixes in particular. Their
comments in reviews are insightful and they have helped to onboard new
reviewers and taken the time to work with people on their patches.

Existing neutron cores, please vote +1/-1 for the addition of Henry
and Kevin to the core team.
Enough time has passed now, and Kevin and Henry have received enough +1 votes. 
So I'd like to welcome them to the core team!

Thanks,
Kyle

Thanks!
Kyle

[1] http://stackalytics.com/report/contribution/neutron-group/180

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/e53c063f/attachment-0001.html>

------------------------------

Message: 8
Date: Tue, 9 Dec 2014 07:28:03 +0000
From: Samuel Bercovici <samu...@radware.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS
        - Use Cases that led us to adopt this.
Message-ID:
        <f36e8145f2571242a675f56cf609645628965...@ilmb1.corp.radware.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I agree that the most important thing is to conclude how status properties are 
being managed and handled so it will remain consistent as we move along.
I am fine with starting with a simple model and expending as need to be.
The L7 implementation is ready waiting for the rest of the model to get in so 
pool sharing under a listener is something that we should solve now.
I think that pool sharing under listeners connected to the same LB is more 
common that what you describe.

-Sam.


From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Tuesday, December 09, 2014 12:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

So...  I should probably note that I see the case where a user actually shares 
object as being the exception. I expect that 90% of deployments will never need 
to share objects, except for a few cases--  those cases (of 1:N) relationships 
are:

* Loadbalancers must be able to have many Listeners
* When L7 functionality is introduced, L7 policies must be able to refer to the 
same Pool under a single Listener. (That is to say, sharing Pools under the 
scope of a single Listener makes sense, but only after L7 policies are 
introduced.)

I specifically see the following kind of sharing having near zero demand:

* Listeners shared across multiple loadbalancers
* Pools shared across multiple listeners
* Members shared across multiple pools

So, despite the fact that sharing doesn't make status reporting any more or 
less complex, I'm still in favor of starting with 1:1 relationships between 
most kinds of objects and then changing those to 1:N or M:N as we get user 
demand for this. As I said in my first response, allowing too many many to many 
relationships feels like a solution to a problem that doesn't really exist, and 
introduces a lot of unnecessary complexity.

Stephen

On Sun, Dec 7, 2014 at 11:43 PM, Samuel Bercovici 
<samu...@radware.com<mailto:samu...@radware.com>> wrote:
+1


From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>]
Sent: Friday, December 05, 2014 7:59 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

German-- but the point is that sharing apparently has no effect on the number 
of permutations for status information. The only difference here is that 
without sharing it's more work for the user to maintain and modify trees of 
objects.

On Fri, Dec 5, 2014 at 9:36 AM, Eichberger, German 
<german.eichber...@hp.com<mailto:german.eichber...@hp.com>> wrote:
Hi Brandon + Stephen,

Having all those permutations (and potentially testing them) made us lean 
against the sharing case in the first place. It?s just a lot of extra work for 
only a small number of our customers.

German

From: Stephen Balukoff 
[mailto:sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>]
Sent: Thursday, December 04, 2014 9:17 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
Cases that led us to adopt this.

Hi Brandon,

Yeah, in your example, member1 could potentially have 8 different statuses (and 
this is a small example!)...  If that member starts flapping, it means that 
every time it flaps there are 8 notifications being passed upstream.

Note that this problem actually doesn't get any better if we're not sharing 
objects but are just duplicating them (ie. not sharing objects but the user 
makes references to the same back-end machine as 8 different members.)

To be honest, I don't see sharing entities at many levels like this being the 
rule for most of our installations-- maybe a few percentage points of 
installations will do an excessive sharing of members, but I doubt it. So 
really, even though reporting status like this is likely to generate a pretty 
big tree of data, I don't think this is actually a problem, eh. And I don't see 
sharing entities actually reducing the workload of what needs to happen behind 
the scenes. (It just allows us to conceal more of this work from the user.)

Stephen



On Thu, Dec 4, 2014 at 4:05 PM, Brandon Logan 
<brandon.lo...@rackspace.com<mailto:brandon.lo...@rackspace.com>> wrote:
Sorry it's taken me a while to respond to this.

So I wasn't thinking about this correctly.  I was afraid you would have
to pass in a full tree of parent child representations to /loadbalancers
to update anything a load balancer it is associated to (including down
to members).  However, after thinking about it, a user would just make
an association call on each object.  For Example, associate member1 with
pool1, associate pool1 with listener1, then associate loadbalancer1 with
listener1.  Updating is just as simple as updating each entity.

This does bring up another problem though.  If a listener can live on
many load balancers, and a pool can live on many listeners, and a member
can live on many pools, there's lot of permutations to keep track of for
status.  you can't just link a member's status to a load balancer bc a
member can exist on many pools under that load balancer, and each pool
can exist under many listeners under that load balancer.  For example,
say I have these:

lb1
lb2
listener1
listener2
pool1
pool2
member1
member2

lb1 -> [listener1, listener2]
lb2 -> [listener1]
listener1 -> [pool1, pool2]
listener2 -> [pool1]
pool1 -> [member1, member2]
pool2 -> [member1]

member1 can now have a different statuses under pool1 and pool2.  since
listener1 and listener2 both have pool1, this means member1 will now
have a different status for listener1 -> pool1 and listener2 -> pool2
combination.  And so forth for load balancers.

Basically there's a lot of permutations and combinations to keep track
of with this model for statuses.  Showing these in the body of load
balancer details can get quite large.

I hope this makes sense because my brain is ready to explode.

Thanks,
Brandon

On Thu, 2014-11-27 at 08:52 +0000, Samuel Bercovici wrote:
> Brandon, can you please explain further (1) bellow?
>
> -----Original Message-----
> From: Brandon Logan 
> [mailto:brandon.lo...@rackspace.com<mailto:brandon.lo...@rackspace.com>]
> Sent: Tuesday, November 25, 2014 12:23 AM
> To: 
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use 
> Cases that led us to adopt this.
>
> My impression is that the statuses of each entity will be shown on a detailed 
> info request of a loadbalancer.  The root level objects would not have any 
> statuses.  For example a user makes a GET request to /loadbalancers/{lb_id} 
> and the status of every child of that load balancer is show in a 
> "status_tree" json object.  For example:
>
> {"name": "loadbalancer1",
>  "status_tree":
>   {"listeners":
>     [{"name": "listener1", "operating_status": "ACTIVE",
>       "default_pool":
>         {"name": "pool1", "status": "ACTIVE",
>          "members":
>            [{"ip_address": "10.0.0.1", "status": "OFFLINE"}]}}
>
> Sam, correct me if I am wrong.
>
> I generally like this idea.  I do have a few reservations with this:
>
> 1) Creating and updating a load balancer requires a full tree configuration 
> with the current extension/plugin logic in neutron.  Since updates will 
> require a full tree, it means the user would have to know the full tree 
> configuration just to simply update a name.  Solving this would require 
> nested child resources in the URL, which the current neutron extension/plugin 
> does not allow.  Maybe the new one will.
>
> 2) The status_tree can get quite large depending on the number of listeners 
> and pools being used.  This is a minor issue really as it will make horizon's 
> (or any other UI tool's) job easier to show statuses.
>
> Thanks,
> Brandon
>
> On Mon, 2014-11-24 at 12:43 -0800, Stephen Balukoff wrote:
> > Hi Samuel,
> >
> >
> > We've actually been avoiding having a deeper discussion about status
> > in Neutron LBaaS since this can get pretty hairy as the back-end
> > implementations get more complicated. I suspect managing that is
> > probably one of the bigger reasons we have disagreements around object
> > sharing. Perhaps it's time we discussed representing state "correctly"
> > (whatever that means), instead of a round-a-bout discussion about
> > object sharing (which, I think, is really just avoiding this issue)?
> >
> >
> > Do you have a proposal about how status should be represented
> > (possibly including a description of the state machine) if we collapse
> > everything down to be logical objects except the loadbalancer object?
> > (From what you're proposing, I suspect it might be too general to, for
> > example, represent the UP/DOWN status of members of a given pool.)
> >
> >
> > Also, from an haproxy perspective, sharing pools within a single
> > listener actually isn't a problem. That is to say, having the same
> > L7Policy pointing at the same pool is OK, so I personally don't have a
> > problem allowing sharing of objects within the scope of parent
> > objects. What do the rest of y'all think?
> >
> >
> > Stephen
> >
> >
> >
> > On Sat, Nov 22, 2014 at 11:06 PM, Samuel Bercovici
> > <samu...@radware.com<mailto:samu...@radware.com>> wrote:
> >         Hi Stephen,
> >
> >
> >
> >         1.      The issue is that if we do 1:1 and allow status/state
> >         to proliferate throughout all objects we will then get an
> >         issue to fix it later, hence even if we do not do sharing, I
> >         would still like to have all objects besides LB be treated as
> >         logical.
> >
> >         2.      The 3rd use case bellow will not be reasonable without
> >         pool sharing between different policies. Specifying different
> >         pools which are the same for each policy make it non-started
> >         to me.
> >
> >
> >
> >         -Sam.
> >
> >
> >
> >
> >
> >
> >
> >         From: Stephen Balukoff 
> > [mailto:sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>]
> >         Sent: Friday, November 21, 2014 10:26 PM
> >         To: OpenStack Development Mailing List (not for usage
> >         questions)
> >         Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects
> >         in LBaaS - Use Cases that led us to adopt this.
> >
> >
> >
> >         I think the idea was to implement 1:1 initially to reduce the
> >         amount of code and operational complexity we'd have to deal
> >         with in initial revisions of LBaaS v2. Many to many can be
> >         simulated in this scenario, though it does shift the burden of
> >         maintenance to the end user. It does greatly simplify the
> >         initial code for v2, in any case, though.
> >
> >
> >
> >
> >
> >         Did we ever agree to allowing listeners to be shared among
> >         load balancers?  I think that still might be a N:1
> >         relationship even in our latest models.
> >
> >
> >
> >
> >         There's also the difficulty introduced by supporting different
> >         flavors:  Since flavors are essentially an association between
> >         a load balancer object and a driver (with parameters), once
> >         flavors are introduced, any sub-objects of a given load
> >         balancer objects must necessarily be purely logical until they
> >         are associated with a load balancer.  I know there was talk of
> >         forcing these objects to be sub-objects of a load balancer
> >         which can't be accessed independently of the load balancer
> >         (which would have much the same effect as what you discuss:
> >         State / status only make sense once logical objects have an
> >         instantiation somewhere.) However, the currently proposed API
> >         treats most objects as root objects, which breaks this
> >         paradigm.
> >
> >
> >
> >
> >
> >         How we handle status and updates once there's an instantiation
> >         of these logical objects is where we start getting into real
> >         complexity.
> >
> >
> >
> >
> >
> >         It seems to me there's a lot of complexity introduced when we
> >         allow a lot of many to many relationships without a whole lot
> >         of benefit in real-world deployment scenarios. In most cases,
> >         objects are not going to be shared, and in those cases with
> >         sufficiently complicated deployments in which shared objects
> >         could be used, the user is likely to be sophisticated enough
> >         and skilled enough to manage updating what are essentially
> >         "copies" of objects, and would likely have an opinion about
> >         how individual failures should be handled which wouldn't
> >         necessarily coincide with what we developers of the system
> >         would assume. That is to say, allowing too many many to many
> >         relationships feels like a solution to a problem that doesn't
> >         really exist, and introduces a lot of unnecessary complexity.
> >
> >
> >
> >
> >
> >         In any case, though, I feel like we should walk before we run:
> >         Implementing 1:1 initially is a good idea to get us rolling.
> >         Whether we then implement 1:N or M:N after that is another
> >         question entirely. But in any case, it seems like a bad idea
> >         to try to start with M:N.
> >
> >
> >
> >
> >
> >         Stephen
> >
> >
> >
> >
> >
> >
> >
> >         On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici
> >         <samu...@radware.com<mailto:samu...@radware.com>> wrote:
> >
> >         Hi,
> >
> >         Per discussion I had at OpenStack Summit/Paris with Brandon
> >         and Doug, I would like to remind everyone why we choose to
> >         follow a model where pools and listeners are shared (many to
> >         many relationships).
> >
> >         Use Cases:
> >         1. The same application is being exposed via different LB
> >         objects.
> >         For example: users coming from the internal "private"
> >         organization network, have an LB1(private_VIP) -->
> >         Listener1(TLS) -->Pool1 and user coming from the "internet",
> >         have LB2(public_vip)-->Listener1(TLS)-->Pool1.
> >         This may also happen to support ipv4 and ipv6: LB_v4(ipv4_VIP)
> >         --> Listener1(TLS) -->Pool1 and LB_v6(ipv6_VIP) -->
> >         Listener1(TLS) -->Pool1
> >         The operator would like to be able to manage the pool
> >         membership in cases of updates and error in a single place.
> >
> >         2. The same group of servers is being used via different
> >         listeners optionally also connected to different LB objects.
> >         For example: users coming from the internal "private"
> >         organization network, have an LB1(private_VIP) -->
> >         Listener1(HTTP) -->Pool1 and user coming from the "internet",
> >         have LB2(public_vip)-->Listener2(TLS)-->Pool1.
> >         The LBs may use different flavors as LB2 needs TLS termination
> >         and may prefer a different "stronger" flavor.
> >         The operator would like to be able to manage the pool
> >         membership in cases of updates and error in a single place.
> >
> >         3. The same group of servers is being used in several
> >         different L7_Policies connected to a listener. Such listener
> >         may be reused as in use case 1.
> >         For example: LB1(VIP1)-->Listener_L7(TLS)
> >                                                     |
> >
> >         +-->L7_Policy1(rules..)-->Pool1
> >                                                     |
> >
> >         +-->L7_Policy2(rules..)-->Pool2
> >                                                     |
> >
> >         +-->L7_Policy3(rules..)-->Pool1
> >                                                     |
> >
> >         +-->L7_Policy3(rules..)-->Reject
> >
> >
> >         I think that the "key" issue handling correctly the
> >         "provisioning" state and the operation state in a many to many
> >         model.
> >         This is an issue as we have attached status fields to each and
> >         every object in the model.
> >         A side effect of the above is that to understand the
> >         "provisioning/operation" status one needs to check many
> >         different objects.
> >
> >         To remedy this, I would like to turn all objects besides the
> >         LB to be logical objects. This means that the only place to
> >         manage the status/state will be on the LB object.
> >         Such status should be hierarchical so that logical object
> >         attached to an LB, would have their status consumed out of the
> >         LB object itself (in case of an error).
> >         We also need to discuss how modifications of a logical object
> >         will be "rendered" to the concrete LB objects.
> >         You may want to revisit
> >         
> > https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r
> >  the "Logical Model + Provisioning Status + Operation Status + Statistics" 
> > for a somewhat more detailed explanation albeit it uses the LBaaS v1 model 
> > as a reference.
> >
> >         Regards,
> >                 -Sam.
> >
> >
> >
> >
> >
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         
> > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> >
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> >
> >
> >         --
> >
> >         Stephen Balukoff
> >         Blue Box Group, LLC
> >         (800)613-4305 x807<tel:%28800%29613-4305%20x807>
> >
> >
> >
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         
> > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> >
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> > --
> > Stephen Balukoff
> > Blue Box Group, LLC
> > (800)613-4305 x807<tel:%28800%29613-4305%20x807>
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807<tel:%28800%29613-4305%20x807>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807<tel:%28800%29613-4305%20x807>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/dafa4e7e/attachment-0001.html>

------------------------------

Message: 9
Date: Mon, 8 Dec 2014 23:39:38 -0800
From: W Chan <m4d.co...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Mistral] Action context passed to all action
        executions by default
Message-ID:
        <cabny8o72cfrspvp0vq_p3ub2viqxo4xy7o0kep8ea8ekti2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Renat,

Is there any reason why Mistral do not pass action context such as workflow
ID, execution ID, task ID, and etc to all of the action executions?  I
think it makes a lot of sense for that information to be made available by
default.  The action can then decide what to do with the information. It
doesn't require a special signature in the __init__ method of the Action
classes.  What do you think?

Thanks.
Winson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141208/a0238f56/attachment-0001.html>

------------------------------

Message: 10
Date: Tue, 09 Dec 2014 09:38:50 +0100
From: Thierry Carrez <thie...@openstack.org>
To: OpenStack Development Mailing List
        <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] Cross-Project meeting, Tue December 9th,
        21:00 UTC
Message-ID: <5486b51a.6080...@openstack.org>
Content-Type: text/plain; charset=utf-8

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

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

* Convergence on specs process (johnthetubaguy)
  * Approval process differences
  * Path structure differences
  * specs.o.o aspect differences (toc)
* osprofiler config options (kragniz)
  * Glance uses a different name from other projects
  * Consensus on what name to use
* Open discussion & announcements

See you there !

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

-- 
Thierry Carrez (ttx)



------------------------------

Message: 11
Date: Tue, 9 Dec 2014 14:48:10 +0600
From: Renat Akhmerov <rakhme...@mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Mistral] Query on creating multiple
        resources
Message-ID: <8cc8fe04-056a-4574-926b-baf5b7749...@mirantis.com>
Content-Type: text/plain; charset=utf-8

Hey,

I think it?s a question of what the final goal is. For just creating security 
groups as a resource I think Georgy and Zane are right, just use Heat. If the 
goal is to try Mistral or have this simple workflow as part of more complex 
then it?s totally fine to use Mistral. Sorry, I?m probably biased because 
Mistral is our baby :). Anyway, Nikolay has already answered the question 
technically, this ?for-each? feature will be available officially in about 2 
weeks.

> Create VM workflow was a demo example. Mistral potentially can be used by 
> Heat or other orchestration tools to do actual interaction with API, but for 
> user it might be easier to use Heat functionality.

I kind of disagree with that statement. Mistral can be used by whoever finds 
its useful for their needs. Standard ?create_instance? workflow (which is in 
?resources/workflows/create_instance.yaml?) is not so a demo example as well. 
It does a lot of good stuff you may really need in your case (e.g. retry 
policies). Even though it?s true that it has some limitations we?re aware of. 
For example, when it comes to configuring a network for newly created instance 
it?s now missing network related parameters to be able to alter behavior.

One more thing: Now only will Heat be able to call Mistral somewhere underneath 
the surface. Mistral has already integration with Heat to be able to call it if 
needed and there?s a plan to make it even more useful and usable.

Thanks

Renat Akhmerov
@ Mirantis Inc.




------------------------------

Message: 12
Date: Tue, 9 Dec 2014 14:49:32 +0600
From: Renat Akhmerov <rakhme...@mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Mistral] Query on creating multiple
        resources
Message-ID: <33d7e423-9fdd-4d3d-9d0b-65ada9378...@mirantis.com>
Content-Type: text/plain; charset="iso-8859-1"

No problem, let us know if you have any other questions.

Renat Akhmerov
@ Mirantis Inc.



> On 09 Dec 2014, at 11:57, Sushma Korati <sushma_kor...@persistent.com> wrote:
> 
> 
> Hi,
> 
> Thank you guys.
> 
> Yes I am able to do this with heat, but I faced issues while trying the same 
> with mistral.
> As suggested will try with the latest mistral branch. Thank you once again. 
> 
> Regards,
> Sushma
> 
> 
> 
>  
> From: Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com 
> <mailto:gokrokvertsk...@mirantis.com>] 
> Sent: Tuesday, December 09, 2014 6:07 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Mistral] Query on creating multiple resources
>  
> Hi Sushma,
>  
> Did you explore Heat templates? As Zane mentioned you can do this via Heat 
> template without writing any workflows. 
> Do you have any specific use cases which you can't solve with Heat template?
>  
> Create VM workflow was a demo example. Mistral potentially can be used by 
> Heat or other orchestration tools to do actual interaction with API, but for 
> user it might be easier to use Heat functionality.
>  
> Thanks,
> Georgy
>  
> On Mon, Dec 8, 2014 at 7:54 AM, Nikolay Makhotkin <nmakhot...@mirantis.com 
> <mailto:nmakhot...@mirantis.com>> wrote:
> Hi, Sushma! 
> 
> Can we create multiple resources using a single task, like multiple keypairs 
> or security-groups or networks etc?
>  
> Yes, we can. This feature is in the development now and it is considered as 
> experimental 
> -https://blueprints.launchpad.net/mistral/+spec/mistral-dataflow-collections 
> <https://blueprints.launchpad.net/mistral/+spec/mistral-dataflow-collections>
>  
> Just clone the last master branch from mistral.
> 
> You can specify "for-each" task property and provide the array of data to 
> your workflow: 
> 
>  --------------------
> version: '2.0'
> 
> name: secgroup_actions
> 
> workflows:
>   create_security_group:
>     type: direct
>     input:
>       - array_with_names_and_descriptions
> 
>     tasks:
>       create_secgroups:
>         for-each: 
>           data: $.array_with_names_and_descriptions
>         action: nova.security_groups_create name={$.data.name 
> <http://data.name/>} description={$.data.description}
> ------------
>  
> On Mon, Dec 8, 2014 at 6:36 PM, Zane Bitter <zbit...@redhat.com 
> <mailto:zbit...@redhat.com>> wrote:
> On 08/12/14 09:41, Sushma Korati wrote:
> Can we create multiple resources using a single task, like multiple
> keypairs or security-groups or networks etc?
> 
> Define them in a Heat template and create the Heat stack as a single task.
> 
> - ZB
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
>  
> -- 
> Best Regards,
> Nikolay
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
>  
> -- 
> Georgy Okrokvertskhov
> Architect,
> OpenStack Platform Products,
> Mirantis
> http://www.mirantis.com <http://www.mirantis.com/>
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
> DISCLAIMER ========== This e-mail may contain privileged and confidential 
> information which is the property of Persistent Systems Ltd. It is intended 
> only for the use of the individual or entity to which it is addressed. If you 
> are not the intended recipient, you are not authorized to read, retain, copy, 
> print, distribute or use this message. If you have received this 
> communication in error, please notify the sender and delete all copies of 
> this message. Persistent Systems Ltd. does not accept any liability for virus 
> infected mails.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/b16a3f9f/attachment-0001.html>

------------------------------

Message: 13
Date: Tue, 9 Dec 2014 14:52:38 +0600
From: Renat Akhmerov <rakhme...@mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Mistral] Event Subscription
Message-ID: <17c46bd9-f6f6-43ae-883e-2512ee698...@mirantis.com>
Content-Type: text/plain; charset="utf-8"

Ok, got it.

So my general suggestion here is: let's keep it as simple as possible for now, 
create something that works and then let?s see how to improve it. And yes, 
consumers may be and mostly will be 3rd parties.

Thanks

Renat Akhmerov
@ Mirantis Inc.



> On 09 Dec 2014, at 08:25, W Chan <m4d.co...@gmail.com> wrote:
> 
> Renat,
> 
> On sending events to an "exchange", I mean an exchange on the transport (i.e. 
> rabbitMQ exchange https://www.rabbitmq.com/tutorials/amqp-concepts.html 
> <https://www.rabbitmq.com/tutorials/amqp-concepts.html>).  On implementation 
> we can probably explore the notification feature in oslo.messaging.  But on 
> second thought, this would limit the consumers to trusted subsystems or 
> services though.  If we want the event consumers to be any 3rd party, 
> including untrusted, then maybe we should keep it as HTTP calls.
> 
> Winson
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/5f5eb550/attachment-0001.html>

------------------------------

Message: 14
Date: Tue, 9 Dec 2014 15:22:28 +0600
From: Renat Akhmerov <rakhme...@mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Mistral] Action context passed to all
        action  executions by default
Message-ID: <74548dcf-f417-4ea8-b3ae-cdd3024a0...@mirantis.com>
Content-Type: text/plain; charset=us-ascii

Hi Winson,

I think it makes perfect sense. The reason I think is mostly historical and 
this can be reviewed now. Can you pls file a BP and describe your suggested 
design on that? I mean how we need to alter interface Action etc.

Thanks

Renat Akhmerov
@ Mirantis Inc.



> On 09 Dec 2014, at 13:39, W Chan <m4d.co...@gmail.com> wrote:
> 
> Renat,
> 
> Is there any reason why Mistral do not pass action context such as workflow 
> ID, execution ID, task ID, and etc to all of the action executions?  I think 
> it makes a lot of sense for that information to be made available by default. 
>  The action can then decide what to do with the information. It doesn't 
> require a special signature in the __init__ method of the Action classes.  
> What do you think?
> 
> Thanks.
> Winson
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




------------------------------

Message: 15
Date: Tue, 9 Dec 2014 09:33:47 +0000
From: joehuang <joehu...@huawei.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] Cross-Project meeting, Tue December 9th,
        21:00 UTC
Message-ID:
        
<5e7a3d1bf5fd014e86e5f971cf446eff541fb...@szxema505-mbs.china.huawei.com>
        
Content-Type: text/plain; charset="us-ascii"

Hi,
 
If time is available, how about adding one agenda to guide the direction for 
cascading to move forward? Thanks in advance.

The topic is : " Need cross-program decision to run cascading as an incubated 
project mode or register BP separately in each involved project. CI for 
cascading is quite different from traditional test environment, at least 3 
OpenStack instance required for cross OpenStack networking test cases. "  

--------------------------------------------------------------------------------------------------------------------------------
In the 40 minutes cross-project summit session "Approaches for scaling out"[1], 
almost 100 peoples attended the meeting, and the conclusion is that cells can 
not cover the use cases and requirements which the OpenStack cascading 
solution[2] aim to address, the background including use cases and requirements 
is also described in the mail.

After the summit, we just ported the PoC[3] source code from IceHouse based to 
Juno based.

Now, let's move forward:

The major task is to introduce new driver/agent to existing core projects, for 
the core idea of cascading is to add Nova as the hypervisor backend of Nova, 
Cinder as the block storage backend of Cinder, Neutron as the backend of 
Neutron, Glance as one image location of Glance, Ceilometer as the store of 
Ceilometer.
a). Need cross-program decision to run cascading as an incubated project mode 
or register BP separately in each involved project. CI for cascading is quite 
different from traditional test environment, at least 3 OpenStack instance 
required for cross OpenStack networking test cases.
b). Volunteer as the cross project coordinator.
c). Volunteers for implementation and CI. (Already 6 engineers working on 
cascading in the project StackForge/tricircle)

Background of OpenStack cascading vs cells:

1. Use cases
a). Vodafone use case[4](OpenStack summit speech video from 9'02" to 12'30" ), 
establishing globally addressable tenants which result in efficient services 
deployment.
b). Telefonica use case[5], create virtual DC( data center) cross multiple 
physical DCs with seamless experience.
c). ETSI NFV use cases[6], especially use case #1, #2, #3, #5, #6, 8#. For NFV 
cloud, it's in nature the cloud will be distributed but inter-connected in many 
data centers.

2.requirements
a). The operator has multiple sites cloud; each site can use one or multiple 
vendor's OpenStack distributions.
b). Each site with its own requirements and upgrade schedule while maintaining 
standard OpenStack API
c). The multi-site cloud must provide unified resource management with global 
Open API exposed, for example create virtual DC cross multiple physical DCs 
with seamless experience.
Although a prosperity orchestration layer could be developed for the multi-site 
cloud, but it's prosperity API in the north bound interface. The cloud 
operators want the ecosystem friendly global open API for the mutli-site cloud 
for global access.

3. What problems does cascading solve that cells doesn't cover:
OpenStack cascading solution is "OpenStack orchestrate OpenStacks". The core 
architecture idea of OpenStack cascading is to add Nova as the hypervisor 
backend of Nova, Cinder as the block storage backend of Cinder, Neutron as the 
backend of Neutron, Glance as one image location of Glance, Ceilometer as the 
store of Ceilometer. Thus OpenStack is able to orchestrate OpenStacks (from 
different vendor's distribution, or different version ) which may located in 
different sites (or data centers ) through the OpenStack API, meanwhile the 
cloud still expose OpenStack API as the north-bound API in the cloud level.

4. Why cells can't do that:
Cells provide the scale out capability to Nova, but from the OpenStack as a 
whole point of view, it's still working like one OpenStack instance.
a). if Cells is deployed with shared Cinder, Neutron, Glance, Ceilometer. This 
approach provides the multi-site cloud with one unified API endpoint and 
unified resource management, but consolidation of multi-vendor/multi-version 
OpenStack instances across one or more data centers cannot be fulfilled.
b). Each site installed one child cell and accompanied standalone Cinder, 
Neutron(or Nova-network), Glance, Ceilometer. This approach makes 
multi-vendor/multi-version OpenStack distribution co-existence in multi-site 
seem to be feasible, but the requirement for unified API endpoint and unified 
resource management cannot be fulfilled. Cross Neutron networking automation is 
also missing, which should otherwise be done manually or use proprietary 
orchestration layer.

For more information about cascading and cells, please refer to the discussion 
thread before Paris Summit [7].

[1]Approaches for scaling out: 
https://etherpad.openstack.org/p/kilo-crossproject-scale-out-openstack
[2]OpenStack cascading solution: 
https://wiki.openstack.org/wiki/OpenStack_cascading_solution
[3]Cascading PoC: https://github.com/stackforge/tricircle
[4]Vodafone use case (9'02" to 12'30"): 
https://www.youtube.com/watch?v=-KOJYvhmxQI
[5]Telefonica use case: 
http://www.telefonica.com/en/descargas/mwc/present_20140224.pdf
[6]ETSI NFV use cases: 
http://www.etsi.org/deliver/etsi_gs/nfv/001_099/001/01.01.01_60/gs_nfv001v010101p.pdf
[7]Cascading thread before design summit: 
http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-td54115.html


Best Regards
Chaoyi Huang ( Joe Huang )

-----Original Message-----
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Tuesday, December 09, 2014 4:39 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Cross-Project meeting, Tue December 9th, 21:00 UTC

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

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

* Convergence on specs process (johnthetubaguy)
  * Approval process differences
  * Path structure differences
  * specs.o.o aspect differences (toc)
* osprofiler config options (kragniz)
  * Glance uses a different name from other projects
  * Consensus on what name to use
* Open discussion & announcements

See you there !

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

--
Thierry Carrez (ttx)

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



------------------------------

Message: 16
Date: Tue, 9 Dec 2014 09:52:11 +0000
From: "Fox, Kevin M" <kevin....@pnnl.gov>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Cc: "Luohao \(brian\)" <brian.luo...@huawei.com>
Subject: Re: [openstack-dev] [Ironic] Some questions about Ironic
        service
Message-ID:
        <1a3c52dfcd06494d8528644858247bf017815...@ex10mbox03.pnnl.gov>
Content-Type: text/plain; charset="windows-1252"

No to questions 1, 3, and 4. Yes to 2, but very minimally.

________________________________
From: xianchaobo
Sent: Monday, December 08, 2014 10:29:50 PM
To: openstack-dev@lists.openstack.org
Cc: Luohao (brian)
Subject: [openstack-dev] [Ironic] Some questions about Ironic service

Hello, all

I?m trying to install and configure Ironic service, something confused me.
I create two neutron networks, public network and private network.
Private network is used to deploy physical machines
Public network is used to provide floating ip.


(1)     Private network type can be VLAN or VXLAN? (In install guide, the 
network type is flat)

(2)     The network of deployed physical machines can be managed by neutron?

(3)     Different tenants can have its own network to manage physical machines?

(4)     Does the ironic provide some mechanism for deployed physical machines

to use storage such as shared storage,cinder volume?

Thanks,
XianChaobo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/fd95de5d/attachment-0001.html>

------------------------------

Message: 17
Date: Tue, 9 Dec 2014 10:53:19 +0100
From: Maxime Leroy <maxime.le...@6wind.com>
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech
        driver/L2 and vif_driver
Message-ID:
        <caeykdvrsnmn0-oafc0b1mzmj5+10avfiighokc_fr6ffyad...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi there.

I would like some clarification regarding support of out-of-tree
plugin in nova and in neutron.

First, on neutron side, there are mechanisms to support out-of-tree
plugin for L2 plugin (core_plugin) and ML2 mech driver
(stevedore/entrypoint).

Most of ML2/L2 plugins need to have a specific vif driver. As the
vif_driver configuration option in nova has been removed of Juno, it's
not possible to have anymore external Mech driver/L2 plugin.

The nova community takes the decision to stop supporting VIF driver
classes as a public extension point. (ref
http://lists.openstack.org/pipermail/openstack-dev/2014-August/043174.html)

At the opposite, the neutron community still continues to support
external L2/ML2 mechdriver plugin. And more, the decision to put
out-of-the-tree the monolithic plugins and ML2 Mechanism Drivers has
been taken in the Paris summit (ref
https://review.openstack.org/#/c/134680/15/specs/kilo/core-vendor-decomposition.rst)

I am feeling a bit confused about these two opposite decisions of the
two communities. What am I missing ?

I have also proposed a blueprint to have a new plugin mechanism in
nova to load external vif driver. (nova-specs:
https://review.openstack.org/#/c/136827/ and nova (rfc patch):
https://review.openstack.org/#/c/136857/)

>From my point-of-view of a developer having a plugin framework for
internal/external vif driver seems to be a good thing.
It makes the code more modular and introduce a clear api for vif driver classes.

So far, it raises legitimate questions concerning API stability and
public API that request a wider discussion on the ML (as asking by
John Garbut).

I think having a plugin mechanism and a clear api for vif driver is
not going against this policy:
http://docs.openstack.org/developer/nova/devref/policies.html#out-of-tree-support.

There is no needs to have a stable API. It is up to the owner of the
external VIF driver to ensure that its driver is supported by the
latest API. And not the nova community to manage a stable API for this
external VIF driver. Does it make senses ?

Considering the network V2 API, L2/ML2 mechanism driver and VIF driver
need to exchange information such as: binding:vif_type and
binding:vif_details.

>From my understanding, 'binding:vif_type' and 'binding:vif_details' as
a field part of the public network api. There is no validation
constraints for these fields (see
http://docs.openstack.org/api/openstack-network/2.0/content/binding_ext_ports.html),
it means that any value is accepted by the API. So, the values set in
'binding:vif_type' and 'binding:vif_details' are not part of the
public API. Is my understanding correct ?

What other reasons am I missing to not have VIF driver classes as a
public extension point ?

Thanks in advance for your help.

Maxime



------------------------------

Message: 18
Date: Tue, 9 Dec 2014 09:54:21 +0000
From: "Fox, Kevin M" <kevin....@pnnl.gov>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Ironic] How to get past pxelinux.0
        bootloader?
Message-ID:
        <1a3c52dfcd06494d8528644858247bf017815...@ex10mbox03.pnnl.gov>
Content-Type: text/plain; charset="us-ascii"

You probably want to use the agent driver, not the pxe one. It lets you use 
bootloaders from the image.

________________________________
From: Peeyush Gupta
Sent: Monday, December 08, 2014 10:55:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Ironic] How to get past pxelinux.0 bootloader?

Hi all,

So, I have set up a devstack ironic setup for baremetal deployment. I
have been able to deploy a baremetal node successfully using
pxe_ipmitool driver. Now, I am trying to boot a server where I already
have a bootloader i.e. I don't need pxelinux to go and fetch kernel and
initrd images for me. I want to transfer them directly.

I checked out the code and figured out that there are dhcp opts
available, that are modified using pxe_utils.py, changing it didn't
help. Then I moved to ironic.conf, but here also I only see an option to
add pxe_bootfile_name, which is exactly what I want to avoid. Can anyone
please help me with this situation? I don't want to go through
pxelinux.0 bootloader, I just directly want to transfer kernel and
initrd images.

Thanks.

--
Peeyush Gupta
gpeey...@linux.vnet.ibm.com


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/b1cec6a5/attachment-0001.html>

------------------------------

Message: 19
Date: Tue, 9 Dec 2014 11:09:02 +0100
From: Roman Prykhodchenko <rprikhodche...@mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Ironic] Fuel agent proposal
Message-ID: <2fd74259-fecf-4b5e-99fe-6a3eb6976...@mirantis.com>
Content-Type: text/plain; charset="utf-8"

It is true that IPA and FuelAgent share a lot of functionality in common. 
However there is a major difference between them which is that they are 
intended to be used to solve a different problem.

IPA is a solution for provision-use-destroy-use_by_different_user use-case and 
is really great for using it for providing BM nodes for other OS services or in 
services like Rackspace OnMetal. FuelAgent itself serves for 
provision-use-use-?-use use-case like Fuel or TripleO have.

Those two use-cases require concentration on different details in first place. 
For instance for IPA proper decommissioning is more important than advanced 
disk management, but for FuelAgent priorities are opposite because of obvious 
reasons.

Putting all functionality to a single driver and a single agent may cause 
conflicts in priorities and make a lot of mess inside both the driver and the 
agent. Actually previously changes to IPA were blocked right because of this 
conflict of priorities. Therefore replacing FuelAgent by IPA in where FuelAgent 
is used currently does not seem like a good option because come people (and I?m 
not talking about Mirantis) might loose required features because of different 
priorities.

Having two separate drivers along with two separate agents for those different 
use-cases will allow to have two independent teams that are concentrated on 
what?s really important for a specific use-case. I don?t see any problem in 
overlapping functionality if it?s used differently.


P. S.
I realise that people may be also confused by the fact that FuelAgent is 
actually called like that and is used only in Fuel atm. Our point is to make it 
a simple, powerful and what?s more important a generic tool for provisioning. 
It is not bound to Fuel or Mirantis and if it will cause confusion in the 
future we will even be happy to give it a different and less confusing name.

P. P. S.
Some of the points of this integration do not look generic enough or nice 
enough. We look pragmatic on the stuff and are trying to implement what?s 
possible to implement as the first step. For sure this is going to have a lot 
more steps to make it better and more generic.


> On 09 Dec 2014, at 01:46, Jim Rollenhagen <j...@jimrollenhagen.com> wrote:
> 
> 
> 
> On December 8, 2014 2:23:58 PM PST, Devananda van der Veen 
> <devananda....@gmail.com <mailto:devananda....@gmail.com>> wrote:
>> I'd like to raise this topic for a wider discussion outside of the
>> hallway
>> track and code reviews, where it has thus far mostly remained.
>> 
>> In previous discussions, my understanding has been that the Fuel team
>> sought to use Ironic to manage "pets" rather than "cattle" - and doing
>> so
>> required extending the API and the project's functionality in ways that
>> no
>> one else on the core team agreed with. Perhaps that understanding was
>> wrong
>> (or perhaps not), but in any case, there is now a proposal to add a
>> FuelAgent driver to Ironic. The proposal claims this would meet that
>> teams'
>> needs without requiring changes to the core of Ironic.
>> 
>> https://review.openstack.org/#/c/138115/
> 
> I think it's clear from the review that I share the opinions expressed in 
> this email.
> 
> That said (and hopefully without derailing the thread too much), I'm curious 
> how this driver could do software RAID or LVM without modifying Ironic's API 
> or data model. How would the agent know how these should be built? How would 
> an operator or user tell Ironic what the disk/partition/volume layout would 
> look like?
> 
> And before it's said - no, I don't think vendor passthru API calls are an 
> appropriate answer here.
> 
> // jim
> 
>> 
>> The Problem Description section calls out four things, which have all
>> been
>> discussed previously (some are here [0]). I would like to address each
>> one,
>> invite discussion on whether or not these are, in fact, problems facing
>> Ironic (not whether they are problems for someone, somewhere), and then
>> ask
>> why these necessitate a new driver be added to the project.
>> 
>> 
>> They are, for reference:
>> 
>> 1. limited partition support
>> 
>> 2. no software RAID support
>> 
>> 3. no LVM support
>> 
>> 4. no support for hardware that lacks a BMC
>> 
>> #1.
>> 
>> When deploying a partition image (eg, QCOW format), Ironic's PXE deploy
>> driver performs only the minimal partitioning necessary to fulfill its
>> mission as an OpenStack service: respect the user's request for root,
>> swap,
>> and ephemeral partition sizes. When deploying a whole-disk image,
>> Ironic
>> does not perform any partitioning -- such is left up to the operator
>> who
>> created the disk image.
>> 
>> Support for arbitrarily complex partition layouts is not required by,
>> nor
>> does it facilitate, the goal of provisioning physical servers via a
>> common
>> cloud API. Additionally, as with #3 below, nothing prevents a user from
>> creating more partitions in unallocated disk space once they have
>> access to
>> their instance. Therefor, I don't see how Ironic's minimal support for
>> partitioning is a problem for the project.
>> 
>> #2.
>> 
>> There is no support for defining a RAID in Ironic today, at all,
>> whether
>> software or hardware. Several proposals were floated last cycle; one is
>> under review right now for DRAC support [1], and there are multiple
>> call
>> outs for RAID building in the state machine mega-spec [2]. Any such
>> support
>> for hardware RAID will necessarily be abstract enough to support
>> multiple
>> hardware vendor's driver implementations and both in-band creation (via
>> IPA) and out-of-band creation (via vendor tools).
>> 
>> Given the above, it may become possible to add software RAID support to
>> IPA
>> in the future, under the same abstraction. This would closely tie the
>> deploy agent to the images it deploys (the latter image's kernel would
>> be
>> dependent upon a software RAID built by the former), but this would
>> necessarily be true for the proposed FuelAgent as well.
>> 
>> I don't see this as a compelling reason to add a new driver to the
>> project.
>> Instead, we should (plan to) add support for software RAID to the
>> deploy
>> agent which is already part of the project.
>> 
>> #3.
>> 
>> LVM volumes can easily be added by a user (after provisioning) within
>> unallocated disk space for non-root partitions. I have not yet seen a
>> compelling argument for doing this within the provisioning phase.
>> 
>> #4.
>> 
>> There are already in-tree drivers [3] [4] [5] which do not require a
>> BMC.
>> One of these uses SSH to connect and run pre-determined commands. Like
>> the
>> spec proposal, which states at line 122, "Control via SSH access
>> feature
>> intended only for experiments in non-production environment," the
>> current
>> SSHPowerDriver is only meant for testing environments. We could
>> probably
>> extend this driver to do what the FuelAgent spec proposes, as far as
>> remote
>> power control for cheap always-on hardware in testing environments with
>> a
>> pre-shared key.
>> 
>> (And if anyone wonders about a use case for Ironic without external
>> power
>> control ... I can only think of one situation where I would rationally
>> ever
>> want to have a control-plane agent running inside a user-instance: I am
>> both the operator and the only user of the cloud.)
>> 
>> 
>> ----------------
>> 
>> In summary, as far as I can tell, all of the problem statements upon
>> which
>> the FuelAgent proposal are based are solvable through incremental
>> changes
>> in existing drivers, or out of scope for the project entirely. As
>> another
>> software-based deploy agent, FuelAgent would duplicate the majority of
>> the
>> functionality which ironic-python-agent has today.
>> 
>> Ironic's driver ecosystem benefits from a diversity of
>> hardware-enablement
>> drivers. Today, we have two divergent software deployment drivers which
>> approach image deployment differently: "agent" drivers use a local
>> agent to
>> prepare a system and download the image; "pxe" drivers use a remote
>> agent
>> and copy the image over iSCSI. I don't understand how a second driver
>> which
>> duplicates the functionality we already have, and shares the same goals
>> as
>> the drivers we already have, is beneficial to the project.
>> 
>> Doing the same thing twice just increases the burden on the team; we're
>> all
>> working on the same problems, so let's do it together.
>> 
>> -Devananda
>> 
>> 
>> [0]
>> https://blueprints.launchpad.net/ironic/+spec/ironic-python-agent-partition
>> 
>> [1] https://review.openstack.org/#/c/107981/
>> 
>> [2]
>> https://review.openstack.org/#/c/133828/11/specs/kilo/new-ironic-state-machine.rst
>> 
>> 
>> [3]
>> http://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/snmp.py
>> 
>> [4]
>> http://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/iboot.py
>> 
>> [5]
>> http://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/ssh.py
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/228c5d08/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/228c5d08/attachment-0001.pgp>

------------------------------

Message: 20
Date: Tue, 09 Dec 2014 15:51:39 +0530
From: Peeyush Gupta <gpeey...@linux.vnet.ibm.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Ironic] How to get past pxelinux.0
        bootloader?
Message-ID: <5486cd33.4000...@linux.vnet.ibm.com>
Content-Type: text/plain; charset="iso-8859-1"

So, basically if I am using pxe driver, I would "have to" provide
pxelinux.0?

On 12/09/2014 03:24 PM, Fox, Kevin M wrote:
> You probably want to use the agent driver, not the pxe one. It lets you use 
> bootloaders from the image.
>
> ________________________________
> From: Peeyush Gupta
> Sent: Monday, December 08, 2014 10:55:39 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Ironic] How to get past pxelinux.0 bootloader?
>
> Hi all,
>
> So, I have set up a devstack ironic setup for baremetal deployment. I
> have been able to deploy a baremetal node successfully using
> pxe_ipmitool driver. Now, I am trying to boot a server where I already
> have a bootloader i.e. I don't need pxelinux to go and fetch kernel and
> initrd images for me. I want to transfer them directly.
>
> I checked out the code and figured out that there are dhcp opts
> available, that are modified using pxe_utils.py, changing it didn't
> help. Then I moved to ironic.conf, but here also I only see an option to
> add pxe_bootfile_name, which is exactly what I want to avoid. Can anyone
> please help me with this situation? I don't want to go through
> pxelinux.0 bootloader, I just directly want to transfer kernel and
> initrd images.
>
> Thanks.
>
> --
> Peeyush Gupta
> gpeey...@linux.vnet.ibm.com
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Peeyush Gupta
gpeey...@linux.vnet.ibm.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/6d9a8ba6/attachment-0001.html>

------------------------------

Message: 21
Date: Tue, 09 Dec 2014 11:32:26 +0100
From: Thierry Carrez <thie...@openstack.org>
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Cross-Project meeting, Tue December 9th,
        21:00 UTC
Message-ID: <5486cfba.8030...@openstack.org>
Content-Type: text/plain; charset=windows-1252

joehuang wrote:
> If time is available, how about adding one agenda to guide the direction for 
> cascading to move forward? Thanks in advance.
> 
> The topic is : " Need cross-program decision to run cascading as an incubated 
> project mode or register BP separately in each involved project. CI for 
> cascading is quite different from traditional test environment, at least 3 
> OpenStack instance required for cross OpenStack networking test cases. "  

Hi Joe, we close the agenda one day before the meeting to let people
arrange their attendance based on the published agenda.

I added your topic in the backlog for next week agenda:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

Regards,

-- 
Thierry Carrez (ttx)



------------------------------

Message: 22
Date: Tue, 9 Dec 2014 11:33:01 +0100
From: Miguel ?ngel Ajo <majop...@redhat.com>
To: OpenStack Development Mailing List
        <openstack-dev@lists.openstack.org>
Subject: [openstack-dev]  [neutron] mid-cycle "hot reviews"
Message-ID: <7a64f4a9f9054721a45db25c9e5a1...@redhat.com>
Content-Type: text/plain; charset="utf-8"


Hi all!

  It would be great if you could use this thread to post hot reviews on stuff  
that it?s being worked out during the mid-cycle, where others from different
timezones could participate.

  I know posting reviews to the list is not permitted, but I think an exception 
 
in this case would be beneficial.

  Best regards,
Miguel ?ngel Ajo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/b716eff4/attachment-0001.html>

------------------------------

Message: 23
Date: Tue, 9 Dec 2014 12:36:08 +0200
From: Tihomir Trifonov <t.trifo...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
        <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [horizon] REST and Django
Message-ID:
        <CAH=QEeCX3+kVV7WrQhYYsapFhm=wjnm4mwkq7k5mdvcr0g+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Sorry for the late reply, just few thoughts on the matter.

IMO the REST middleware should be as thin as possible. And I mean thin in
terms of processing - it should not do pre/post processing of the requests,
but just unpack/pack. So here is an example:

instead of making AJAX calls that contain instructions:

??
> POST --json --data {"action": "delete", "data": [ {"name":
> "item1"}, {"name": "item2"}, {"name": "item3" ]}


I think a better approach is just to pack/unpack batch commands, and leave
execution to the frontend/backend and not middleware:


??
> POST --json --data {"
> ?batch
> ":
> ?[
> {?
> "
> ?
> action"
> ? : "delete"?
> ,
> ?"payload": ?
> {"name": "item1"}
> ?,
> {?
> "
> ?
> action"
> ? : "delete"?
> ,
> ?
> "payload":
> ?
> {"name": "item
> ?2
> "}
> ?,
> {?
> "
> ?
> action"
> ? : "delete"?
> ,
> ?
> "payload":
> ?
> {"name": "item
> ?3
> "}
> ? ] ?
> ?
> ?
> }


?The idea is that the middleware should not know the actual data. It should
ideally just unpack the data:

??responses = []
>

for cmd in
> ? ?
> ?
> ?
> request.POST['batch']:?


> ?
> ??responses
> ?.append(?
> ?
> getattr(controller, cmd['action']
> ?)(**
> cmd['?payload']
> ?)?)
>

> ?return responses?
>


?and the frontend(JS) will just send batches of simple commands, and will
receive a list of responses for each command in the batch. The error
handling will be done in the frontend?(JS) as well.

?

For the more complex example of 'put()' where we have dependent objects:

project = api.keystone.tenant_get(request, id)
> kwargs = self._tenant_kwargs_from_DATA(request.DATA, enabled=None)
> api.keystone.tenant_update(request, project, **kwargs)



In practice the project data should be already present in the
frontend(assuming that we already loaded it to render the project
form/view), so

?
?
POST --json --data {"
?batch
":
?[
{?
"
?
action"
? : "tenant_update"?
,
?"payload": ?
{"project": js_project_object.id, "name": "some name", "prop1": "some
prop", "prop2": "other prop, etc."}
?
? ] ?
?
?
}?

So in general we don't need to recreate the full state on each REST call,
if we make the Frontent full-featured application. This way - the frontend
will construct the object, will hold the cached value, and will just send
the needed requests as single ones or in batches, will receive the response
from the API backend, and will render the results. The whole processing
logic will be held in the Frontend(JS), while the middleware will just act
as proxy(un/packer). This way we will maintain just the logic in the
frontend, and will not need to duplicate some logic in the middleware.




On Tue, Dec 2, 2014 at 4:45 PM, Adam Young <ayo...@redhat.com> wrote:

>  On 12/02/2014 12:39 AM, Richard Jones wrote:
>
> On Mon Dec 01 2014 at 4:18:42 PM Thai Q Tran <tqt...@us.ibm.com> wrote:
>
>>  I agree that keeping the API layer thin would be ideal. I should add
>> that having discrete API calls would allow dynamic population of table.
>> However, I will make a case where it *might* be necessary to add
>> additional APIs. Consider that you want to delete 3 items in a given table.
>>
>> If you do this on the client side, you would need to perform: n * (1 API
>> request + 1 AJAX request)
>> If you have some logic on the server side that batch delete actions: n *
>> (1 API request) + 1 AJAX request
>>
>> Consider the following:
>> n = 1, client = 2 trips, server = 2 trips
>> n = 3, client = 6 trips, server = 4 trips
>> n = 10, client = 20 trips, server = 11 trips
>> n = 100, client = 200 trips, server 101 trips
>>
>> As you can see, this does not scale very well.... something to consider...
>>
>  This is not something Horizon can fix.  Horizon can make matters worse,
> but cannot make things better.
>
> If you want to delete 3 users,   Horizon still needs to make 3 distinct
> calls to Keystone.
>
> To fix this, we need either batch calls or a standard way to do multiples
> of the same operation.
>
> The unified API effort it the right place to drive this.
>
>
>
>
>
>
>
>  Yep, though in the above cases the client is still going to be hanging,
> waiting for those server-backend calls, with no feedback until it's all
> done. I would hope that the client-server call overhead is minimal, but I
> guess that's probably wishful thinking when in the land of random Internet
> users hitting some provider's Horizon :)
>
>  So yeah, having mulled it over myself I agree that it's useful to have
> batch operations implemented in the POST handler, the most common operation
> being DELETE.
>
>  Maybe one day we could transition to a batch call with user feedback
> using a websocket connection.
>
>
>       Richard
>
>>  [image: Inactive hide details for Richard Jones ---11/27/2014 05:38:53
>> PM---On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S <travis.tr]Richard
>> Jones ---11/27/2014 05:38:53 PM---On Fri Nov 28 2014 at 5:58:00 AM Tripp,
>> Travis S <travis.tr...@hp.com> wrote:
>>
>> From: Richard Jones <r1chardj0...@gmail.com>
>> To: "Tripp, Travis S" <travis.tr...@hp.com>, OpenStack List <
>> openstack-dev@lists.openstack.org>
>> Date: 11/27/2014 05:38 PM
>> Subject: Re: [openstack-dev] [horizon] REST and Django
>>  ------------------------------
>>
>>
>>
>>
>> On Fri Nov 28 2014 at 5:58:00 AM Tripp, Travis S <*travis.tr...@hp.com*
>> <travis.tr...@hp.com>> wrote:
>>
>>    Hi Richard,
>>
>>    You are right, we should put this out on the main ML, so copying
>>    thread out to there.  ML: FYI that this started after some impromptu IRC
>>    discussions about a specific patch led into an impromptu google hangout
>>    discussion with all the people on the thread below.
>>
>>
>> Thanks Travis!
>>
>>
>>
>>    As I mentioned in the review[1], Thai and I were mainly discussing
>>    the possible performance implications of network hops from client to
>>    horizon server and whether or not any aggregation should occur server 
>> side.
>>      In other words, some views  require several APIs to be queried before 
>> any
>>    data can displayed and it would eliminate some extra network requests from
>>    client to server if some of the data was first collected on the server 
>> side
>>    across service APIs.  For example, the launch instance wizard will need to
>>    collect data from quite a few APIs before even the first step is displayed
>>    (I?ve listed those out in the blueprint [2]).
>>
>>    The flip side to that (as you also pointed out) is that if we keep
>>    the API?s fine grained then the wizard will be able to optimize in one
>>    place the calls for data as it is needed. For example, the first step may
>>    only need half of the API calls. It also could lead to perceived
>>    performance increases just due to the wizard making a call for different
>>    data independently and displaying it as soon as it can.
>>
>>
>> Indeed, looking at the current launch wizard code it seems like you
>> wouldn't need to load all that data for the wizard to be displayed, since
>> only some subset of it would be necessary to display any given panel of the
>> wizard.
>>
>>
>>
>>    I tend to lean towards your POV and starting with discrete API calls
>>    and letting the client optimize calls.  If there are performance problems
>>    or other reasons then doing data aggregation on the server side could be
>>    considered at that point.
>>
>>
>> I'm glad to hear it. I'm a fan of optimising when necessary, and not
>> beforehand :)
>>
>>
>>
>>    Of course if anybody is able to do some performance testing between
>>    the two approaches then that could affect the direction taken.
>>
>>
>> I would certainly like to see us take some measurements when performance
>> issues pop up. Optimising without solid metrics is bad idea :)
>>
>>
>>     Richard
>>
>>
>>
>>    [1]
>>    
>> *https://review.openstack.org/#/c/136676/8/openstack_dashboard/api/rest/urls.py*
>>    
>> <https://review.openstack.org/#/c/136676/8/openstack_dashboard/api/rest/urls.py>
>>    [2]
>>    *https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign*
>>    <https://blueprints.launchpad.net/horizon/+spec/launch-instance-redesign>
>>
>>    -Travis
>>
>>    *From: *Richard Jones <*r1chardj0...@gmail.com*
>>    <r1chardj0...@gmail.com>>
>> * Date: *Wednesday, November 26, 2014 at 11:55 PM
>> * To: *Travis Tripp <*travis.tr...@hp.com* <travis.tr...@hp.com>>, Thai
>>    Q Tran/Silicon Valley/IBM <*tqt...@us.ibm.com* <tqt...@us.ibm.com>>,
>>    David Lyle <*dkly...@gmail.com* <dkly...@gmail.com>>, Maxime Vidori <
>>    *maxime.vid...@enovance.com* <maxime.vid...@enovance.com>>,
>>    "Wroblewski, Szymon" <*szymon.wroblew...@intel.com*
>>    <szymon.wroblew...@intel.com>>, "Wood, Matthew David (HP Cloud -
>>    Horizon)" <*matt.w...@hp.com* <matt.w...@hp.com>>, "Chen, Shaoquan" <
>>    *sean.ch...@hp.com* <sean.ch...@hp.com>>, "Farina, Matt (HP Cloud)" <
>>    *matthew.far...@hp.com* <matthew.far...@hp.com>>, Cindy Lu/Silicon
>>    Valley/IBM <*c...@us.ibm.com* <c...@us.ibm.com>>, Justin
>>    Pomeroy/Rochester/IBM <*jpom...@us.ibm.com* <jpom...@us.ibm.com>>,
>>    Neill Cox <*neill....@ingenious.com.au* <neill....@ingenious.com.au>>
>> * Subject: *Re: REST and Django
>>
>>    I'm not sure whether this is the appropriate place to discuss this,
>>    or whether I should be posting to the list under [Horizon] but I think we
>>    need to have a clear idea of what goes in the REST API and what goes in 
>> the
>>    client (angular) code.
>>
>>    In my mind, the thinner the REST API the better. Indeed if we can get
>>    away with proxying requests through without touching any *client code, 
>> that
>>    would be great.
>>
>>    Coding additional logic into the REST API means that a developer
>>    would need to look in two places, instead of one, to determine what was
>>    happening for a particular call. If we keep it thin then the API presented
>>    to the client developer is very, very similar to the API presented by the
>>    services. Minimum surprise.
>>
>>    Your thoughts?
>>
>>
>>         Richard
>>
>>
>>    On Wed Nov 26 2014 at 2:40:52 PM Richard Jones <
>>    *r1chardj0...@gmail.com* <r1chardj0...@gmail.com>> wrote:
>>
>>
>>     Thanks for the great summary, Travis.
>>
>>       I've completed the work I pledged this morning, so now the REST
>>       API change set has:
>>
>>       - no rest framework dependency
>>       - AJAX scaffolding in openstack_dashboard.api.rest.utils
>>       - code in openstack_dashboard/api/rest/
>>       - renamed the API from "identity" to "keystone" to be consistent
>>       - added a sample of testing, mostly for my own sanity to check
>>       things were working
>>
>>       *https://review.openstack.org/#/c/136676*
>>       <https://review.openstack.org/#/c/136676>
>>
>>
>>             Richard
>>
>>       On Wed Nov 26 2014 at 12:18:25 PM Tripp, Travis S <
>>       *travis.tr...@hp.com* <travis.tr...@hp.com>> wrote:
>>
>>
>>     Hello all,
>>
>>          Great discussion on the REST urls today! I think that we are on
>>          track to come to a common REST API usage pattern.  To provide quick 
>> summary:
>>
>>          We all agreed that going to a straight REST pattern rather than
>>          through tables was a good idea. We discussed using direct get / 
>> post in
>>          Django views like what Max originally used[1][2] and Thai also 
>> started[3]
>>          with the identity table rework or to go with djangorestframework 
>> [5] like
>>          what Richard was prototyping with[4].
>>
>>          The main things we would use from Django Rest Framework were
>>          built in JSON serialization (avoid boilerplate), better exception 
>> handling,
>>          and some request wrapping.  However, we all weren?t sure about the 
>> need for
>>          a full new framework just for that. At the end of the conversation, 
>> we
>>          decided that it was a cleaner approach, but Richard would see if he 
>> could
>>          provide some utility code to do that much for us without requiring 
>> the full
>>          framework.  David voiced that he doesn?t want us building out a 
>> whole
>>          framework on our own either.
>>
>>          So, Richard will do some investigation during his day today and
>>          get back to us.  Whatever the case, we?ll get a patch in horizon 
>> for the
>>          base dependency (framework or Richard?s utilities) that both Thai?s 
>> work
>>          and the launch instance work is dependent upon.  We?ll build REST 
>> style
>>          API?s using the same pattern.  We will likely put the rest api?s in
>>          horizon/openstack_dashboard/api/rest/.
>>
>>          [1]
>>          
>> *https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py*
>>          
>> <https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/keypair.py>
>>          [2]
>>          
>> *https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py*
>>          
>> <https://review.openstack.org/#/c/133178/1/openstack_dashboard/workflow/launch.py>
>>          [3]
>>          
>> *https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py*
>>          
>> <https://review.openstack.org/#/c/133767/8/openstack_dashboard/dashboards/identity/users/views.py>
>>          [4]
>>          
>> *https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py*
>>          
>> <https://review.openstack.org/#/c/136676/4/openstack_dashboard/rest_api/identity.py>
>>          [5] *http://www.django-rest-framework.org/*
>>          <http://www.django-rest-framework.org/>
>>
>>          Thanks,
>>
>>
>>     Travis_______________________________________________
>>          OpenStack-dev mailing list
>>          OpenStack-dev@lists.openstack.org
>>
>>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>  _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Tihomir Trifonov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/953fe3e7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/953fe3e7/attachment.gif>

------------------------------

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


End of OpenStack-dev Digest, Vol 32, Issue 25
*********************************************
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to