[openstack-dev] vms come up on a different bridge..
Prashanth Prahalad
prashanth.prahal at gmail.com
Thu Apr 18 16:52:41 UTC 2013
Thanks Shake,
Turned out to be a problem with this :
> bridge name bridge id STP enabled interfaces
> br-eth2 8000.000cfc01f473 no eth2
Removing eth2 from br-eth2 fixes this. The quantum agent subsequently
plumbs eth2 onto the other bridge
brq3c2d19b3-fa 8000.000cfc01f473 no eth2
tap72b8463c-6f
tapa6c9775d-df
tapadbf1b11-e9
tapc6c54b78-87
tapcf424b48-54
tapdb58671d-bd
tapdb661e2b-ff
tapfbe88e01-78
Regards,
Prashanth
Hi Prashanth
whether can share your netwrok interface setting /etc/netwrok/interface.
I am not sure the setting .
physical_interface_mappings = physnet2:eth2
what I need to setting in eth2?
On Wed, Apr 17, 2013 at 11:38 PM, Prashanth Prahalad <
prashanth.prahal at gmail.com> wrote:
> Hi Folks,
>
> I'm setting up quantum with linux bridge. I might have configured this
> incorrectly and looking for some help on what could be going on.
>
> This is my quantum.conf and linuxbridge_conf.ini - which tries to setup
> the linux bridge over eth2.
>
> [DEFAULT]
> auth_strategy = keystone
> allow_overlapping_ips = True
> policy_file = /etc/quantum/policy.json
> debug = True
> verbose = True
> service_plugins =
> quantum.plugins.services.agent_loadbalancer.plugin.LoadBalancerPlugin
> core_plugin =
> quantum.plugins.linuxbridge.lb_quantum_plugin.LinuxBridgePluginV2
> rabbit_password = openstack
> rabbit_host = localhost
> rpc_backend = quantum.openstack.common.rpc.impl_kombu
> state_path = /opt/stack/data/quantum
> debug = True
> verbose = True
> lock_path = $state_path/lock
> log_file = quantum.log
> log_dir = /var/log/quantum
> bind_host = 0.0.0.0
> bind_port = 9696
> <......>
>
> linuxbridge_conf.ini
>
> [VLANS]
> tenant_network_type = vlan
> network_vlan_ranges = physnet2:1000:2999
> [DATABASE]
> sql_connection = mysql://root:openstack@localhost
> /quantum_linux_bridge?charset=utf8
> reconnect_interval = 2
> [LINUX_BRIDGE]
> physical_interface_mappings = physnet2:eth2
> [AGENT]
> root_helper = sudo /usr/local/bin/quantum-rootwrap
> /etc/quantum/rootwrap.conf
> polling_interval = 2
> [SECURITYGROUP]
> firewall_driver =
> quantum.agent.linux.iptables_firewall.IptablesFirewallDriver
>
> But when the VM is booted up, it comes up over brq3c2d19b3-fa instead of
> br-eth2
>
> bridge name bridge id STP enabled interfaces
> br-eth2 8000.000cfc01f473 no eth2
> brq057a0be8-e9 8000.96f0115f0c03 no
> tapa0dcbf6a-73
> brq34f87736-91 8000.32245b5d90b7 no
> tap22c7ffb1-9f
>
> tap874fecfb-ac
> brq3c2d19b3-fa 8000.3a84ed127b7a no
> tapadbf1b11-e9
>
> tapc6c54b78-87
>
> tapcf424b48-54
>
> tapdb58671d-bd
>
> tapdb661e2b-ff
>
> Here's a list of commands :
>
> quantum net-create sharednet1 --shared --provider:network_type=flat -
> provider:physical_network=physnet2
> quantum subnet-create sharednet1 30.0.0.0/24
>
>
> +--------------------------------------+------------+-------
-----------------------------------------------+
> | id | name | subnets
> |
>
> +--------------------------------------+------------+-------
-----------------------------------------------+
> | 057a0be8-e9f9-4e23-a97b-08d2bdb67ad2 | public |
> 92b32336-76d2-4fa3-a5eb-e1a4b76c648c 172.24.4.224/28 |
> | 34f87736-91d6-4f00-ad11-fe39e76638ce | private |
> f315bfd5-5f8a-4fa4-bca2-0814998cf8d5 10.0.0.0/24 |
> | 3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 | sharednet1 |
> 4691c3ca-b769-4454-9997-1b4dd851d602 30.0.0.0/24 |
>
> +--------------------------------------+------------+-------
-----------------------------------------------+
>
> nova boot --image cirros --flavor m1.tiny --nic
> net-id=3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 --key-name test
my_first_server
>
> Anything I'm missing ?
>
> Thanks !
> Prashanth
>
On Thu, Apr 18, 2013 at 5:00 AM,
<openstack-dev-request at lists.openstack.org>wrote:
> Send OpenStack-dev mailing list submissions to
> openstack-dev at 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-request at lists.openstack.org
>
> You can reach the person managing the list at
> openstack-dev-owner at 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. Re: [Quantum] Quantum VPN: Update from today's discussion
> (Sachin Thakkar)
> 2. Re: [Quantum] Quantum VPN: Update from today's discussion
> (Alan Kavanagh)
> 3. Re: [Quantum] Quantum VPN: Update from today's discussion
> (Ian Wells)
> 4. Re: [Quantum] Quantum VPN: Update from today's discussion
> (Yi Yang)
> 5. AUTO: Dietmar Noll/Germany/IBM is out of the office
> (returning 24.04.2013) (Dietmar Noll)
> 6. vms come up on a different bridge.. (Prashanth Prahalad)
> 7. Source for the Swift API spec? (Pete Zaitcev)
> 8. Re: [Heat] TOSCA, CAMP, CloudFormation, ??? (Angus Salkeld)
> 9. Re: Source for the Swift API spec? (Adrian Smith)
> 10. Re: [Quantum] Quantum VPN: Update from today's discussion
> (Nachi Ueno)
> 11. Re: [Quantum] Quantum VPN: Update from today's discussion
> (Vasudevan, Swaminathan (PNB Roseville))
> 12. Re: [Heat] Future Vision for Heat (Steven Hardy)
> 13. Re: [Heat] Future Vision for Heat (Steven Hardy)
> 14. Re: [Heat] Future Vision for Heat (Steven Hardy)
> 15. Re: Source for the Swift API spec? (Anne Gentle)
> 16. Heat/DSL2 (Alex Heneveld)
> 17. Re: [Quantum] Quantum VPN: Update from today's discussion
> (fank at vmware.com)
> 18. Re: Heat/DSL2 (Tripp, Travis S)
> 19. Re: [Heat] Future Vision for Heat (Zane Bitter)
> 20. Re: [Heat] Future Vision for Heat (Zane Bitter)
> 21. Re: Heat/DSL2 (Duncan Johnston Watt)
> 22. Re: [Heat] Future Vision for Heat (Adrian Otto)
> 23. Re: [Quantum] Quantum VPN: Update from today's discussion
> (Nachi Ueno)
> 24. Re: [Quantum] Quantum VPN: Update from today's discussion
> (Alan Kavanagh)
> 25. Re: [Quantum] Quantum VPN: Update from today's discussion
> (Nachi Ueno)
> 26. Workflow as a service: Convection (Roshan)
> 27. AUTO: Avishay Traeger is out of the office (returning
> 05/12/2013) (Avishay Traeger)
> 28. Re: vms come up on a different bridge.. (Shake Chen)
> 29. [Quantum] Quantum VPN discussion (Nachi Ueno)
> 30. Re: [Heat] Future Vision for Heat (Joshua Harlow)
> 31. passwords in logs --security related (Bhandaru, Malini K)
> 32. Re: [Heat] Future Vision for Heat (Adrian Otto)
> 33. Re: passwords in logs --security related (Matt Van Winkle)
> 34. Re: passwords in logs --security related (Matt Van Winkle)
> 35. [Cinder] Raised exception in utils.execute (Yann Fouillat)
> 36. Re: [Heat] Future Vision for Heat (Adrian Otto)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 17 Apr 2013 06:58:51 -0700 (PDT)
> From: Sachin Thakkar <sthakkar at vmware.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID:
> <23962145.1899.1366207131452.JavaMail.sthakkar at sthakkar-mbair.local
> >
> Content-Type: text/plain; charset="utf-8"
>
> I definitely agree with point (1) from Yi below. There are so many flavors
> and intricacies to VPNs that it would be to our advantage to decouple as
> much as possible.
>
> For (2), my understanding is that the quantum VPN could be either. Is your
> comment to add this explicit role in addition to the state fields?
>
> Sachin
>
> ----- Original Message -----
>
> From: "Yi Yang" <yyos1999 at gmail.com>
> To: "OpenStack Development Mailing List" <
> openstack-dev at lists.openstack.org>
> Sent: Wednesday, April 17, 2013 12:42:35 AM
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> discussion
>
> A couple of quick comments:
>
> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,
> as the former adopts a server-client model while the latter doesn't.
>
> 2. One thing missed in these use cases, except in use case 3, is the
> "role" -- does the quantum VPN act as a server or a client?
>
> Yi
>
>
>
> On 4/16/13 8:16 PM, Nachi Ueno wrote:
> > Hi folks
> >
> > Thank you for joining today's discussion.
> > Based on today's discussion, we updated the slide.
> >
> >
> https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
> >
> > Changes
> > - Simplify use case
> > removed any router references because it deals with implementation
> > - Simplify Generic VPNService model
> > removed any router references because it deals with service insertion
> > - Update attributes of generic VPN Service
> > Layer2 or Layer3 mode etc
> >
> > Tommorows' discussion is
> > 5:20 at OpenStack Networking room
> >
> http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g
> >
> > Thanks!
> > Nachi
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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/20130417/b30d0488/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 17 Apr 2013 14:13:31 +0000
> From: Alan Kavanagh <alan.kavanagh at ericsson.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID:
> <C977B257ADF8814C8EB4FB66BB9D0C2E0AB2C4 at eusaamb109.ericsson.se>
> Content-Type: text/plain; charset="us-ascii"
>
> Absolutely Yi. So I think the Use Case Scenario that is being addressed
> dictates what the VPN type or collection of suitable VPN types that can be
> used.
>
> For point 2, lets touch on that at the VPN session today ;-)
>
> Alan
>
> -----Original Message-----
> From: Yi Yang [mailto:yyos1999 at gmail.com]
> Sent: April-17-13 3:43 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> discussion
>
> A couple of quick comments:
>
> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,
> as the former adopts a server-client model while the latter doesn't.
>
> 2. One thing missed in these use cases, except in use case 3, is the
> "role" -- does the quantum VPN act as a server or a client?
>
> Yi
>
>
>
> On 4/16/13 8:16 PM, Nachi Ueno wrote:
> > Hi folks
> >
> > Thank you for joining today's discussion.
> > Based on today's discussion, we updated the slide.
> >
> > https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7
> > B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
> >
> > Changes
> > - Simplify use case
> > removed any router references because it deals with implementation
> > - Simplify Generic VPNService model
> > removed any router references because it deals with service
> > insertion
> > - Update attributes of generic VPN Service
> > Layer2 or Layer3 mode etc
> >
> > Tommorows' discussion is
> > 5:20 at OpenStack Networking room
> > http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335ac
> > c8a78ff61c#.UW3p1SvC82g
> >
> > Thanks!
> > Nachi
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 17 Apr 2013 07:27:29 -0700
> From: Ian Wells <ijw.ubuntu at cack.org.uk>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID:
> <CAPoubz5bjOormU9FkGDN=TKh5oiY+3Hqm6mY8drru=iKKWZL=
> w at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 17 April 2013 00:42, Yi Yang <yyos1999 at gmail.com> wrote:
>
> > 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,
> > as the former adopts a server-client model while the latter doesn't.
> >
>
> Thirded. There are any number of VPNs where the VPN is set up by some form
> of mutual agreement - no negotiation, no connection, merely one end sending
> packets in an agreed format and simultaneously agreeing to process incoming
> ones.
>
> The categorisations I would choose are:
>
> 1. VPN by mutual agreement (and where the connection cannot, typically, be
> rejected) - this would include MPLS, GRE, l2tpv3 and VLANs
> 2. VPN where we provide one set of credentials to the far end, the VPN must
> be activated and may drop and be reactivated, and the connection is
> authorised or rejected on those credentials
> 3. VPN where we're an endpoint with (possibly) many sets of credentials and
> we authorise incoming connections.
>
> (2) and (3) would presumably be the same set of protocols and include
> openvpn, ipsec and friends.
>
> I'm not sure that that covers all the cases, so please chime in with your
> counterexamples.
>
> --
> Ian.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/dbc0bf1e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Wed, 17 Apr 2013 10:38:56 -0400
> From: Yi Yang <yyos1999 at gmail.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID: <516EB400.20904 at gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> While quantum VPN can serve as either client or server or both, there
> are big difference on requirements -- for example, a SSL VPN server
> needs to have an address pool, which is not required for clients.
>
> IMO, we need to first differentiate these use cases (server vs. client)
> before we decide what state fields should be covered.
>
> Yi
>
> On 4/17/13 9:58 AM, Sachin Thakkar wrote:
> > I definitely agree with point (1) from Yi below. There are so many
> > flavors and intricacies to VPNs that it would be to our advantage to
> > decouple as much as possible.
> >
> > For (2), my understanding is that the quantum VPN could be either. Is
> > your comment to add this explicit role in addition to the state fields?
> >
> > Sachin
> >
> > ------------------------------------------------------------------------
> > *From: *"Yi Yang" <yyos1999 at gmail.com>
> > *To: *"OpenStack Development Mailing List"
> > <openstack-dev at lists.openstack.org>
> > *Sent: *Wednesday, April 17, 2013 12:42:35 AM
> > *Subject: *Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> > today's discussion
> >
> > A couple of quick comments:
> >
> > 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,
> > as the former adopts a server-client model while the latter doesn't.
> >
> > 2. One thing missed in these use cases, except in use case 3, is the
> > "role" -- does the quantum VPN act as a server or a client?
> >
> > Yi
> >
> >
> >
> > On 4/16/13 8:16 PM, Nachi Ueno wrote:
> > > Hi folks
> > >
> > > Thank you for joining today's discussion.
> > > Based on today's discussion, we updated the slide.
> > >
> > >
> >
> https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
> > >
> > > Changes
> > > - Simplify use case
> > > removed any router references because it deals with implementation
> > > - Simplify Generic VPNService model
> > > removed any router references because it deals with service
> insertion
> > > - Update attributes of generic VPN Service
> > > Layer2 or Layer3 mode etc
> > >
> > > Tommorows' discussion is
> > > 5:20 at OpenStack Networking room
> > >
> >
> http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g
> > >
> > > Thanks!
> > > Nachi
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at 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/20130417/70ac7937/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Wed, 17 Apr 2013 17:13:22 +0200
> From: Dietmar Noll <DNOLL at de.ibm.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] AUTO: Dietmar Noll/Germany/IBM is out of the
> office (returning 24.04.2013)
> Message-ID:
> <
> OFE28CE9B2.1B2C3038-ONC1257B50.00539F54-C1257B50.00539F54 at de.ibm.com>
> Content-Type: text/plain; charset=US-ASCII
>
>
> I am out of the office until 24.04.2013.
>
> I am out of the office traveling and will only have limited access to
> e-mails.
> I will respond as soon as possible.
> For TPC/VSC related topics, please contact Sumant Padbidri
> For other urgent topics, please contact Horst Zisgen.
>
>
> Note: This is an automated response to your message "OpenStack-dev Digest,
> Vol 12, Issue 21" sent on 17/04/2013 14:00:02.
>
> This is the only notification you will receive while this person is away.
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 17 Apr 2013 08:38:01 -0700
> From: Prashanth Prahalad <prashanth.prahal at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] vms come up on a different bridge..
> Message-ID:
> <CADghgozytDB=
> 6rqA1iPS40ywp9k-EBPkg5L+Rb5p2uwGxEvpKA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Folks,
>
> I'm setting up quantum with linux bridge. I might have configured this
> incorrectly and looking for some help on what could be going on.
>
> This is my quantum.conf and linuxbridge_conf.ini - which tries to setup
> the linux bridge over eth2.
>
> [DEFAULT]
> auth_strategy = keystone
> allow_overlapping_ips = True
> policy_file = /etc/quantum/policy.json
> debug = True
> verbose = True
> service_plugins =
> quantum.plugins.services.agent_loadbalancer.plugin.LoadBalancerPlugin
> core_plugin =
> quantum.plugins.linuxbridge.lb_quantum_plugin.LinuxBridgePluginV2
> rabbit_password = openstack
> rabbit_host = localhost
> rpc_backend = quantum.openstack.common.rpc.impl_kombu
> state_path = /opt/stack/data/quantum
> debug = True
> verbose = True
> lock_path = $state_path/lock
> log_file = quantum.log
> log_dir = /var/log/quantum
> bind_host = 0.0.0.0
> bind_port = 9696
> <......>
>
> linuxbridge_conf.ini
>
> [VLANS]
> tenant_network_type = vlan
> network_vlan_ranges = physnet2:1000:2999
> [DATABASE]
> sql_connection = mysql://root:openstack@localhost
> /quantum_linux_bridge?charset=utf8
> reconnect_interval = 2
> [LINUX_BRIDGE]
> physical_interface_mappings = physnet2:eth2
> [AGENT]
> root_helper = sudo /usr/local/bin/quantum-rootwrap
> /etc/quantum/rootwrap.conf
> polling_interval = 2
> [SECURITYGROUP]
> firewall_driver =
> quantum.agent.linux.iptables_firewall.IptablesFirewallDriver
>
> But when the VM is booted up, it comes up over brq3c2d19b3-fa instead of
> br-eth2
>
> bridge name bridge id STP enabled interfaces
> br-eth2 8000.000cfc01f473 no eth2
> brq057a0be8-e9 8000.96f0115f0c03 no
> tapa0dcbf6a-73
> brq34f87736-91 8000.32245b5d90b7 no
> tap22c7ffb1-9f
>
> tap874fecfb-ac
> brq3c2d19b3-fa 8000.3a84ed127b7a no
> tapadbf1b11-e9
>
> tapc6c54b78-87
>
> tapcf424b48-54
>
> tapdb58671d-bd
>
> tapdb661e2b-ff
>
> Here's a list of commands :
>
> quantum net-create sharednet1 --shared --provider:network_type=flat -
> provider:physical_network=physnet2
> quantum subnet-create sharednet1 30.0.0.0/24
>
>
> +--------------------------------------+------------+------------------------------------------------------+
> | id | name | subnets
> |
>
> +--------------------------------------+------------+------------------------------------------------------+
> | 057a0be8-e9f9-4e23-a97b-08d2bdb67ad2 | public |
> 92b32336-76d2-4fa3-a5eb-e1a4b76c648c 172.24.4.224/28 |
> | 34f87736-91d6-4f00-ad11-fe39e76638ce | private |
> f315bfd5-5f8a-4fa4-bca2-0814998cf8d5 10.0.0.0/24 |
> | 3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 | sharednet1 |
> 4691c3ca-b769-4454-9997-1b4dd851d602 30.0.0.0/24 |
>
> +--------------------------------------+------------+------------------------------------------------------+
>
> nova boot --image cirros --flavor m1.tiny --nic
> net-id=3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 --key-name test my_first_server
>
> Anything I'm missing ?
>
> Thanks !
> Prashanth
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/fd87c076/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 7
> Date: Wed, 17 Apr 2013 11:26:16 -0600
> From: Pete Zaitcev <zaitcev at redhat.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] Source for the Swift API spec?
> Message-ID: <20130417112616.72cd8bed at lembas.zaitcev.lan>
> Content-Type: text/plain; charset=US-ASCII
>
> Just curious after Anne joined a breakfast table and talked about helping
> with the docs: where is the source of the Swift API spec? I'm talking
> about this:
> http://docs.openstack.org/api/openstack-object-storage/1.0/content/
>
> I have manuals repo cloned, but apparently it's not there.
> (this - git://github.com/openstack/openstack-manuals.git)
>
> Obviously it's not in doc/source/ of Swift repo either. But it has to
> be _somewhere_, right?
>
> -- Pete
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 17 Apr 2013 10:56:12 -0700
> From: Angus Salkeld <asalkeld at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???
> Message-ID: <20130417175612.GB4100 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 15/04/13 14:39 -0700, Alex Heneveld wrote:
> >
> >I have refactored and expanded the "vocabulary" (@asalked's madness
> >guide) now at:
> >
> > https://wiki.openstack.org/wiki/Heat/Vocabulary
>
> Thanks Alex.
>
> -Angus
> >
> >--A
> >
> >
> >On 12/04/2013 15:36, Adrian Otto wrote:
> >>Clint,
> >>
> >>On Apr 12, 2013, at 2:22 PM, Clint Byrum <clint at fewbar.com>
> >> wrote:
> >>
> >>>On 2013-04-12 08:45, Adrian Otto wrote:
> >>>>This proposal will utilize the existing Heat agent. We currently use
> >>>>SSH keypair injection on the API call to the Cloud Servers API to
> >>>>bootstrap compute nodes in the simple case. The idea is to leave that
> >>>>open to handle whatever the system Provider modules want to
> >>>>instrument. Please recognize that we want this DSL to work regardless
> >>>>of what the underlying hardware/cloud infrastructure is. It can work
> >>>>on your laptop with vagrant, with OpenStack, with a public cloud? that
> >>>>should not matter. The vendor specific implementations all go into the
> >>>>Provider plug-ins. The idea is to enable decentralized implementation
> >>>>of vendor-specific systems, and centralized sharing of best practices
> >>>>for application deployment. Imagine an OpenStack community repo of
> >>>>Heat Blueprints where everyone can publish their best practices.
> >>>So what I think you're saying is, Heat would have some intrinsic
> providers for compute, object storage, block storage, etc. Users would
> somehow be able to define their own providers inside compute servers via an
> API, which could then be referenced directly in the DSL? So if I want
> memcached, I write a provider definition for it, and somehow deliver it
> into the compute node and notify Heat of its presence?
> >>>
> >>>The spec is really unclear on how providers are defined (or I'm just
> overloaded with specs and can't comprehend it), but I am actually pretty
> excited to see a system that allows users to reference and manage
> compute-hosted things at the same level as "under the cloud" resources.
> >>Yes, you've got the idea. In the case of memcached, you might just want
> to build that up from compute instances, so you might not even involve a
> provider for that, it could simply be specified as a Component. That's not
> any different from what Heat can already do today. Here is another use case
> where Providers can make a lot of sense:
> >>
> >>Goal: Deploy my app on my chosen OpenStack based public cloud, using
> Heat for Dev/Test. For Production, deploy to my private OpenStack cloud.
> >>
> >>Scenario: My app depends on a MySQL database. My public cloud provider
> has a hosted "mysql" service that is offered through a Provider plug-in.
> It's there automatically because my cloud hosting company put it there. I
> deploy, and finish my testing on the public cloud. I want to go to
> production now.
> >>
> >>Solution: The Provider gives you a way to abstract the different cloud
> implementations. I establish an equivalent Provider on my private OpenStack
> cloud using RedDwarf. I set up a Provider that offers "mysql" in my private
> cloud. Now the same setup works on both clouds, even though the API for my
> local "mysql" service may actually differ from the database provisioning
> API in the public cloud. Now I deploy on my "production" Environment in my
> private cloud, and it works!
> >>
> >>Not to blow your mind too much, but in the use case above, we assume
> that each cloud has its own hosted Heat service that speaks the Open
> API+DSL. You could also use one of the Heat services, and *not* the other.
> You define two Environments. One is for "dev/test" and uses Providers on
> the public cloud. The other is for "production", and it uses Providers on
> the private cloud. Now you can just decide where stuff gets provisioned by
> selecting the appropriate Environment. You might decide to just use the
> hosted Heat service from your public cloud, even when you are deploying
> into your private cloud.
> >>
> >>If that makes sense, you can take that idea a step further, and actually
> set up Environments that mix both public and private cloud infrastructure.
> Maybe you use provider A for your mission critical (persistent, HA)
> Components, and provider B for nightly batch processing jobs. Same
> Environment. Arbitrary number of clouds.
> >>
> >>Without a concept like Providers, application portability between public
> and private clouds can get a bit more convoluted. You may end up doing
> things like constructing the "mysql" service on top of compute nodes using
> Components for sake of portability, but this can cause you to sacrifice
> performance using a general purpose compute instances you find in a typical
> nova compute service, rather than the more performance tuned hosted
> database service your public cloud service may offer you.
> >>
> >>Cheers,
> >>
> >>Adrian
> >>
> >>
> >>_______________________________________________
> >>OpenStack-dev mailing list
> >>OpenStack-dev at lists.openstack.org
> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 17 Apr 2013 19:04:10 +0100
> From: Adrian Smith <adrian_f_smith at dell.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Source for the Swift API spec?
> Message-ID:
> <
> CAKgbHu29F0VH0CzkswMaJZaaqPxjSRnZP0y6JsX7C90Pwz6Reg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I think this it the repo Pete, https://github.com/openstack/object-api
>
> Adrian
>
> On 17 April 2013 18:26, Pete Zaitcev <zaitcev at redhat.com> wrote:
> > Just curious after Anne joined a breakfast table and talked about helping
> > with the docs: where is the source of the Swift API spec? I'm talking
> > about this:
> > http://docs.openstack.org/api/openstack-object-storage/1.0/content/
> >
> > I have manuals repo cloned, but apparently it's not there.
> > (this - git://github.com/openstack/openstack-manuals.git)
> >
> > Obviously it's not in doc/source/ of Swift repo either. But it has to
> > be _somewhere_, right?
> >
> > -- Pete
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 17 Apr 2013 11:42:38 -0700
> From: Nachi Ueno <nachi at ntti3.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID:
> <
> CABJepwjM-pK4wNk7EmHPgspuCjBOMZJvFKAmXgqaGw49pR0A5A at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi folks
>
> May be, there are many ways to categorize use cases.
>
> We agreed we will model VPN as a Service instance (VPNService).
> If we define new service, the service can support any kind of VPNs (L2, L3)
> What's we need to be discussed is attributes of Generalize VPN Service
> Models if we can have generic vpn service models.
>
> I added vpn map for slide 13 ( This may help this discussion)
>
> https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310
>
> This is current proposed attributes.
>
> 1. id
> 2. name
> 3. tenant_id
> 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... )
> 5. insertion_mode
> 6. mode = l2 | l3 ?
>
> I believe there is no need to discussion about 1-4.
> 5 is needed to use service insertion.
> ( Prevent routed service insertion of which didn't support it)
>
> 6. Mode
> I'm not sure how to use this attribute, so I'm very appreciate if
> someone would add
> the motivation on the slide
>
> Thanks
> Nachi
>
> 2013/4/17 Yi Yang <yyos1999 at gmail.com>:
> > While quantum VPN can serve as either client or server or both, there are
> > big difference on requirements -- for example, a SSL VPN server needs to
> > have an address pool, which is not required for clients.
> >
> > IMO, we need to first differentiate these use cases (server vs. client)
> > before we decide what state fields should be covered.
> >
> > Yi
> >
> >
> > On 4/17/13 9:58 AM, Sachin Thakkar wrote:
> >
> > I definitely agree with point (1) from Yi below. There are so many
> flavors
> > and intricacies to VPNs that it would be to our advantage to decouple as
> > much as possible.
> >
> > For (2), my understanding is that the quantum VPN could be either. Is
> your
> > comment to add this explicit role in addition to the state fields?
> >
> > Sachin
> >
> > ________________________________
> > From: "Yi Yang" <yyos1999 at gmail.com>
> > To: "OpenStack Development Mailing List" <
> openstack-dev at lists.openstack.org>
> > Sent: Wednesday, April 17, 2013 12:42:35 AM
> > Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> > discussion
> >
> > A couple of quick comments:
> >
> > 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,
> > as the former adopts a server-client model while the latter doesn't.
> >
> > 2. One thing missed in these use cases, except in use case 3, is the
> > "role" -- does the quantum VPN act as a server or a client?
> >
> > Yi
> >
> >
> >
> > On 4/16/13 8:16 PM, Nachi Ueno wrote:
> >> Hi folks
> >>
> >> Thank you for joining today's discussion.
> >> Based on today's discussion, we updated the slide.
> >>
> >>
> >>
> https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
> >>
> >> Changes
> >> - Simplify use case
> >> removed any router references because it deals with implementation
> >> - Simplify Generic VPNService model
> >> removed any router references because it deals with service insertion
> >> - Update attributes of generic VPN Service
> >> Layer2 or Layer3 mode etc
> >>
> >> Tommorows' discussion is
> >> 5:20 at OpenStack Networking room
> >>
> >>
> http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g
> >>
> >> Thanks!
> >> Nachi
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 17 Apr 2013 18:52:49 +0000
> From: "Vasudevan, Swaminathan (PNB Roseville)"
> <swaminathan.vasudevan at hp.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID:
> <
> 4094DC7712AF5D488899847517A3C5B0649E62EB at G9W0342.americas.hpqcorp.net>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Nachi,
> I also added a slide 9, that gives a high level data model for all the vpn
> service types.
> Thanks
> Swami
>
> -----Original Message-----
> From: Nachi Ueno [mailto:nachi at ntti3.com]
> Sent: Wednesday, April 17, 2013 11:43 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> discussion
>
> Hi folks
>
> May be, there are many ways to categorize use cases.
>
> We agreed we will model VPN as a Service instance (VPNService).
> If we define new service, the service can support any kind of VPNs (L2,
> L3) What's we need to be discussed is attributes of Generalize VPN Service
> Models if we can have generic vpn service models.
>
> I added vpn map for slide 13 ( This may help this discussion)
>
> https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310
>
> This is current proposed attributes.
>
> 1. id
> 2. name
> 3. tenant_id
> 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... ) 5. insertion_mode 6.
> mode = l2 | l3 ?
>
> I believe there is no need to discussion about 1-4.
> 5 is needed to use service insertion.
> ( Prevent routed service insertion of which didn't support it)
>
> 6. Mode
> I'm not sure how to use this attribute, so I'm very appreciate if someone
> would add the motivation on the slide
>
> Thanks
> Nachi
>
> 2013/4/17 Yi Yang <yyos1999 at gmail.com>:
> > While quantum VPN can serve as either client or server or both, there
> > are big difference on requirements -- for example, a SSL VPN server
> > needs to have an address pool, which is not required for clients.
> >
> > IMO, we need to first differentiate these use cases (server vs.
> > client) before we decide what state fields should be covered.
> >
> > Yi
> >
> >
> > On 4/17/13 9:58 AM, Sachin Thakkar wrote:
> >
> > I definitely agree with point (1) from Yi below. There are so many
> > flavors and intricacies to VPNs that it would be to our advantage to
> > decouple as much as possible.
> >
> > For (2), my understanding is that the quantum VPN could be either. Is
> > your comment to add this explicit role in addition to the state fields?
> >
> > Sachin
> >
> > ________________________________
> > From: "Yi Yang" <yyos1999 at gmail.com>
> > To: "OpenStack Development Mailing List"
> > <openstack-dev at lists.openstack.org>
> > Sent: Wednesday, April 17, 2013 12:42:35 AM
> > Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> > today's discussion
> >
> > A couple of quick comments:
> >
> > 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN
> > cases, as the former adopts a server-client model while the latter
> doesn't.
> >
> > 2. One thing missed in these use cases, except in use case 3, is the
> > "role" -- does the quantum VPN act as a server or a client?
> >
> > Yi
> >
> >
> >
> > On 4/16/13 8:16 PM, Nachi Ueno wrote:
> >> Hi folks
> >>
> >> Thank you for joining today's discussion.
> >> Based on today's discussion, we updated the slide.
> >>
> >>
> >> https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn
> >> 7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
> >>
> >> Changes
> >> - Simplify use case
> >> removed any router references because it deals with
> >> implementation
> >> - Simplify Generic VPNService model
> >> removed any router references because it deals with service
> >> insertion
> >> - Update attributes of generic VPN Service
> >> Layer2 or Layer3 mode etc
> >>
> >> Tommorows' discussion is
> >> 5:20 at OpenStack Networking room
> >>
> >> http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335a
> >> cc8a78ff61c#.UW3p1SvC82g
> >>
> >> Thanks!
> >> Nachi
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 12
> Date: Wed, 17 Apr 2013 19:54:17 +0100
> From: Steven Hardy <shardy at redhat.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> Message-ID: <20130417185416.GD11493 at t430slt.redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi Adrian,
>
> Thanks for taking the time to do this, definitely provides a good starting
> point for further discussion and captures many of the concepts mentioned
> during the sessions on Monday.
>
> On Tue, Apr 16, 2013 at 08:56:23AM +0000, Adrian Otto wrote:
> > Heaters,
> >
> > I attended the various sessions at the Design Summit today in Portland,
> and assembled as many of the ideas for future planning as I could. For the
> benefit of those who are not attending, or who were not in these sessions,
> I created this Wiki page to express what I think is an early consensus on
> where we could take things. Let's tweak this if it's not a good direction.
> >
> > https://wiki.openstack.org/wiki/Heat/Vision
>
> Thanks for taking the time to do this, definitely provides a good starting
> point for further discussion and captures many of the concepts mentioned
> during the sessions on Monday.
>
> I think your diagram represents a possible long-term view of how the
> architecture could develop, but obviously there are many components there
> which do not currently exist, or which are currently part of the heat core
> orchestration engine.
>
> I think it may be useful to look at the initial modifications required to
> support the new "superset DSL", and I'll try to get a diagram up later with
> my view of what is required to do this, but in summary:
>
> - The model interpreter can be in heat-engine, as the first thing which
> processes the template during template-driven lifecycle operations
> (create/update) - this is separate from the current "parser" logic, so we
> can incrementally modify the underlying parser logic and interpreter
> logic in-step.
>
> - The API layer can be unmodified
>
> - Translations to/from formats other than our current CFN-compatible format
> and the new "Native DSL" (or "HOT" - Heat Openstack Template as was
> suggested on Monday :D) are performed outside of heat - IMO we only want
> to care about the superset DSL inside heat, and we don't want the
> complexity of the stacked API's, multiple model interpreter plugins etc
> (at
> least initially)
>
> - Scheduler/parser logic remains in the heat-engine (this should not ever
> be moved into the API in your diagram IMO)
>
> > Keith will be doing an Unconference session on the Workflow Service
> idea? I believe on Wednesday afternoon.
>
> This definitely sounds interesting, and I'm interested in further
> discussing this idea, see you there!
>
> Steve
>
>
>
> ------------------------------
>
> Message: 13
> Date: Wed, 17 Apr 2013 19:55:06 +0100
> From: Steven Hardy <shardy at redhat.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> Message-ID: <20130417185504.GE11493 at t430slt.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Apr 16, 2013 at 04:13:06PM +0200, Thomas Spatzier wrote:
> > Hi Adrian,
> >
> > thanks for taking writing this up to capture yesterday's discussions.
> > I don't fully understand what the difference or overlap of the Model
> > Interpreter inside the main blue box and the Model Interpreter in the
> green
> > box is. My understanding was that a Model Interpreter would be something
> > that translates an external format (such as CFN, TOSCA, whatever) to the
> > core Heat DSL. And then there would be one component which looks at the
> > common DSL model to derive the deployment plan (I think somebody said
> this
> > is what the "parser" does today).
> > I think having to partly re-implement the interpreter (in the sense of
> > compiling a concrete deployment plan directly) for various external
> formats
> > could be complicated.
>
> I agree, which is why I propose keeping the mult-format translation outside
> of heat (layered above the API, or some scripts which do format conversion)
>
> The "parser" is really our internal terminology, but for the purposes of
> the discussion, the parser is the thing which converts the native template
> format into resource definitions and a dependency-graph we can process
>
> Steve
>
>
>
> ------------------------------
>
> Message: 14
> Date: Wed, 17 Apr 2013 19:56:04 +0100
> From: Steven Hardy <shardy at redhat.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> Message-ID: <20130417185603.GF11493 at t430slt.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Apr 16, 2013 at 01:37:15PM -0700, Alex Heneveld wrote:
> >
> > very useful summary. thanks adrian for this and thanks all for the
> > great discussion yesterday. a few comments:
> >
> > (1) @doug, @thomas: +1. while it would be possible for external
> > servers to understand different models and call REST using a native
> > dsl, it should also be possible to support multiple model
> > interpreters as part of the big blue box. that would seem better
> > for the "legacy" CFN :) and the new DSL (eg YAML) and/or possibly
> > TOSCA XML (or a lite version thereof!).
>
> As mentioned elsewhere, I don't think supporting multiple model
> interpreters internally will be helpful in the short/medium term, the
> maintenance burden will be too high IMO. We should concentrate on
> definining a superset language which is expressive enough that other
> formats people require can be trivially converted either at, or ideally
> above the API level.
>
> >
> > (2) should the workflow service and the scheduler be more closely
> > integrated, or even the same? feels like whatever heat does for its
> > orchestration would want the same task management, scheduling,
> > locking, etc that imperative plans/workflow included as part of a
> > heat blueprint would want.
> >
> > (3) @debojyoti: +1. i'd really like to see support for nested /
> > hierarchical components or typed relationships. this gives a nice
> > solution to services/tiers/pools/autoscaling-groups going up one
> > level but you could go higher too. it makes it composable which
> > becomes very powerful (one of the best features of TOSCA imho). i
> > look forward to the curvature talk (and a visio-style gui for
> > heat!!).
>
> Note we do already support nested/composed stacks - is there some other
> concept or functionality you'd like to see in addition to this?
>
> > finally -- (4) -- is there any interest in continuing the discussion
> > while so many of us are here?
> >
> > i have heard rumours of extra rooms available for the asking.
>
> I'll see if I can find some meeting space - main challenge is everyone has
> pretty packed schedules with all the other sessions that are going on.
>
> I'd definitely like to spend some time white-boarding this and making sure
> we have the vocabulary and concept-mapping side of things agreed.
>
> Steve
>
>
>
> ------------------------------
>
> Message: 15
> Date: Wed, 17 Apr 2013 12:32:32 -0700
> From: Anne Gentle <annegentle at justwriteclick.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Cc: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Source for the Swift API spec?
> Message-ID: <032DADF2-2ED5-42BB-9BD0-63AE0A5C349F at justwriteclick.com>
> Content-Type: text/plain; charset=us-ascii
>
> Yes, that is correct.
>
> Anne Gentle
> Content Stacker
> anne at openstack.org
>
>
> On Apr 17, 2013, at 11:04 AM, Adrian Smith <adrian_f_smith at dell.com>
> wrote:
>
> > I think this it the repo Pete, https://github.com/openstack/object-api
> >
> > Adrian
> >
> > On 17 April 2013 18:26, Pete Zaitcev <zaitcev at redhat.com> wrote:
> >> Just curious after Anne joined a breakfast table and talked about
> helping
> >> with the docs: where is the source of the Swift API spec? I'm talking
> >> about this:
> >> http://docs.openstack.org/api/openstack-object-storage/1.0/content/
> >>
> >> I have manuals repo cloned, but apparently it's not there.
> >> (this - git://github.com/openstack/openstack-manuals.git)
> >>
> >> Obviously it's not in doc/source/ of Swift repo either. But it has to
> >> be _somewhere_, right?
> >>
> >> -- Pete
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 16
> Date: Wed, 17 Apr 2013 12:56:23 -0700
> From: Alex Heneveld <alex.heneveld at cloudsoftcorp.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] Heat/DSL2
> Message-ID: <516EFE67.5010800 at CloudsoftCorp.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> I've been working through the Heat/DSL [1] idea, trying to whittle it
> down to an even simpler model, suitable as an abstraction atop
> CloudFormation as well as TOSCA and CAMP. And like [1] trying to make
> it easy for mortals to read and write.
>
> The current state is at Heat/DSL2 [2], with a rough python parser
> implementation (not connected to Heat yet) at [3].
>
> I'll be around today and tomorrow so if anyone would like to discuss F2F
> or on IRC (alexheneveld) please shout.
>
> Also note there are some related lightning talks starting soon and an
> unconference tomorrow at 2.20pm.
>
> Best
> Alex
>
> [1] https://wiki.openstack.org/wiki/Heat/DSL
> [2] https://wiki.openstack.org/wiki/Heat/DSL2
> [3] https://github.com/sjcorbett/heat-camp-yaml
>
>
>
> ------------------------------
>
> Message: 17
> Date: Wed, 17 Apr 2013 13:27:22 -0700 (PDT)
> From: fank at vmware.com
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID: <955208200.4190562.1366230442506.JavaMail.root at vmware.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi Nachi,
>
> I'm not sure how "insertion_mode" could be any useful for plugins if it
> only indicate the mode as routed/out-of-path/floating insertion.
>
> For example, we need to associated it with a router if it is routed
> insertion (and we have an extension for associating a service with a router
> id:
> https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion).
>
> What we need for out-of-path insertion and floating insertion? A
> network/subnet id?
>
> -Kaiwei
>
> ----- Original Message -----
> From: "Nachi Ueno" <nachi at ntti3.com>
> To: "OpenStack Development Mailing List" <
> openstack-dev at lists.openstack.org>
> Sent: Wednesday, April 17, 2013 11:42:38 AM
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> discussion
>
> Hi folks
>
> May be, there are many ways to categorize use cases.
>
> We agreed we will model VPN as a Service instance (VPNService).
> If we define new service, the service can support any kind of VPNs (L2, L3)
> What's we need to be discussed is attributes of Generalize VPN Service
> Models if we can have generic vpn service models.
>
> I added vpn map for slide 13 ( This may help this discussion)
>
> https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310
>
> This is current proposed attributes.
>
> 1. id
> 2. name
> 3. tenant_id
> 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... )
> 5. insertion_mode
> 6. mode = l2 | l3 ?
>
> I believe there is no need to discussion about 1-4.
> 5 is needed to use service insertion.
> ( Prevent routed service insertion of which didn't support it)
>
> 6. Mode
> I'm not sure how to use this attribute, so I'm very appreciate if
> someone would add
> the motivation on the slide
>
> Thanks
> Nachi
>
> 2013/4/17 Yi Yang <yyos1999 at gmail.com>:
> > While quantum VPN can serve as either client or server or both, there are
> > big difference on requirements -- for example, a SSL VPN server needs to
> > have an address pool, which is not required for clients.
> >
> > IMO, we need to first differentiate these use cases (server vs. client)
> > before we decide what state fields should be covered.
> >
> > Yi
> >
> >
> > On 4/17/13 9:58 AM, Sachin Thakkar wrote:
> >
> > I definitely agree with point (1) from Yi below. There are so many
> flavors
> > and intricacies to VPNs that it would be to our advantage to decouple as
> > much as possible.
> >
> > For (2), my understanding is that the quantum VPN could be either. Is
> your
> > comment to add this explicit role in addition to the state fields?
> >
> > Sachin
> >
> > ________________________________
> > From: "Yi Yang" <yyos1999 at gmail.com>
> > To: "OpenStack Development Mailing List" <
> openstack-dev at lists.openstack.org>
> > Sent: Wednesday, April 17, 2013 12:42:35 AM
> > Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> > discussion
> >
> > A couple of quick comments:
> >
> > 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,
> > as the former adopts a server-client model while the latter doesn't.
> >
> > 2. One thing missed in these use cases, except in use case 3, is the
> > "role" -- does the quantum VPN act as a server or a client?
> >
> > Yi
> >
> >
> >
> > On 4/16/13 8:16 PM, Nachi Ueno wrote:
> >> Hi folks
> >>
> >> Thank you for joining today's discussion.
> >> Based on today's discussion, we updated the slide.
> >>
> >>
> >>
> https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
> >>
> >> Changes
> >> - Simplify use case
> >> removed any router references because it deals with implementation
> >> - Simplify Generic VPNService model
> >> removed any router references because it deals with service insertion
> >> - Update attributes of generic VPN Service
> >> Layer2 or Layer3 mode etc
> >>
> >> Tommorows' discussion is
> >> 5:20 at OpenStack Networking room
> >>
> >>
> http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g
> >>
> >> Thanks!
> >> Nachi
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 18
> Date: Wed, 17 Apr 2013 21:37:28 +0000
> From: "Tripp, Travis S" <travis.tripp at hp.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Heat/DSL2
> Message-ID:
> <
> AD38C991545E8641B21449D96872D72E36BC6512 at G9W0343.americas.hpqcorp.net>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Alex,
>
> When are the lightning talks?
>
> Travis
>
> -----Original Message-----
> From: Alex Heneveld [mailto:alex.heneveld at cloudsoftcorp.com]
> Sent: Wednesday, April 17, 2013 12:56 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] Heat/DSL2
>
>
> I've been working through the Heat/DSL [1] idea, trying to whittle it down
> to an even simpler model, suitable as an abstraction atop CloudFormation as
> well as TOSCA and CAMP. And like [1] trying to make it easy for mortals to
> read and write.
>
> The current state is at Heat/DSL2 [2], with a rough python parser
> implementation (not connected to Heat yet) at [3].
>
> I'll be around today and tomorrow so if anyone would like to discuss F2F
> or on IRC (alexheneveld) please shout.
>
> Also note there are some related lightning talks starting soon and an
> unconference tomorrow at 2.20pm.
>
> Best
> Alex
>
> [1] https://wiki.openstack.org/wiki/Heat/DSL
> [2] https://wiki.openstack.org/wiki/Heat/DSL2
> [3] https://github.com/sjcorbett/heat-camp-yaml
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 19
> Date: Wed, 17 Apr 2013 14:47:43 -0700
> From: Zane Bitter <zbitter at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> Message-ID: <516F187F.8060309 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Thanks Adrian!
>
> We should probably make it clear for those who can't be at Summit that
> this is not intended to be a record of the design summit discussions.
> I'd describe this as a snapshot of Adrian's evolving vision for Heat,
> taken after the design summit sessions. In particular, I think it
> reflects a couple of misconceptions about the current architecture of
> Heat, and it also contains some stuff that hasn't been discussed at all
> at Summit (e.g. the CEP part... btw my initial reaction to this is that
> it should probably talk to Ceilometer rather than the Autoscaling service).
>
> That said, there certainly *is* consensus that we want to evolve Heat
> toward being able to orchestrate whole applications rather than just
> services. We'll be doing further work throughout the week and
> subsequently on the mailing list to refine some of these architectural
> ideas, and we're looking forward to working with Adrian and his team at
> Rackspace to make it happen :)
>
> cheers,
> Zane.
>
> On 16/04/13 01:56, Adrian Otto wrote:
> > Heaters,
> >
> > I attended the various sessions at the Design Summit today in Portland,
> and assembled as many of the ideas for future planning as I could. For the
> benefit of those who are not attending, or who were not in these sessions,
> I created this Wiki page to express what I think is an early consensus on
> where we could take things. Let's tweak this if it's not a good direction.
> >
> > https://wiki.openstack.org/wiki/Heat/Vision
> >
> > Keith will be doing an Unconference session on the Workflow Service
> idea? I believe on Wednesday afternoon.
> >
> > Thanks,
> >
> > Adrian
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
>
> ------------------------------
>
> Message: 20
> Date: Wed, 17 Apr 2013 14:53:48 -0700
> From: Zane Bitter <zbitter at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> Message-ID: <516F19EC.8040201 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 16/04/13 09:05, Thomas Spatzier wrote:
> > Hi Adrian,
> >
> > Adrian Otto <adrian.otto at rackspace.com> wrote on 16.04.2013 17:24:56:
> >> From: Adrian Otto <adrian.otto at rackspace.com>
> >> To: OpenStack Development Mailing List
> > <openstack-dev at lists.openstack.org>,
> >> Date: 16.04.2013 17:26
> >> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> >>
> >> Thanks Thomas. Good point.
> >>
> >> In that case, wwe could just consider the one within the blue area
> >> to have the label "Parser" and that should clarify matters. I'm
> >> happy to make tweaks to clarify it.
> >
> > Maybe we can also come up with a better term than "parser". Would be
> > interested what the Heat core team thinks.
>
> For historical reasons, "parser" is the name of the module that
> essentially runs the Heat orchestration engine. It's a terrible name
> that doesn't really reflect what it actually does, so I'm definitely in
> favour of changing it.
>
> This diagram is also showing it in the wrong place, so we have some more
> work to do to figure out some better terminology and get everyone on the
> same page.
>
> cheers,
> Zane.
>
> >
> > Regards,
> > Thomas
> >
> >>
> >> Adrian
> >>
> >>
> >> -----Original message-----
> >> From: Thomas Spatzier <thomas.spatzier at de.ibm.com>
> >> To: OpenStack Development Mailing List
> > <openstack-dev at lists.openstack.org>
> >> Sent: Tue, Apr 16, 2013 14:22:07 GMT+00:00
> >> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> >
> >> Hi Adrian,
> >>
> >> thanks for taking writing this up to capture yesterday's discussions.
> >> I don't fully understand what the difference or overlap of the Model
> >> Interpreter inside the main blue box and the Model Interpreter in the
> > green
> >> box is. My understanding was that a Model Interpreter would be something
> >> that translates an external format (such as CFN, TOSCA, whatever) to the
> >> core Heat DSL. And then there would be one component which looks at the
> >> common DSL model to derive the deployment plan (I think somebody said
> > this
> >> is what the "parser" does today).
> >> I think having to partly re-implement the interpreter (in the sense of
> >> compiling a concrete deployment plan directly) for various external
> > formats
> >> could be complicated.
> >>
> >> Adrian Otto <adrian.otto at rackspace.com> wrote on 16.04.2013 10:56:23:
> >>
> >>> From: Adrian Otto <adrian.otto at rackspace.com>
> >>> To: OpenStack Development Mailing List
> >> <openstack-dev at lists.openstack.org>,
> >>> Date: 16.04.2013 10:57
> >>> Subject: [openstack-dev] [Heat] Future Vision for Heat
> >>>
> >>> Heaters,
> >>>
> >>> I attended the various sessions at the Design Summit today in
> >>> Portland, and assembled as many of the ideas for future planning as
> >>> I could. For the benefit of those who are not attending, or who
> >>> were not in these sessions, I created this Wiki page to express what
> >>> I think is an early consensus on where we could take things. Let's
> >>> tweak this if it's not a good direction.
> >>>
> >>> https://wiki.openstack.org/wiki/Heat/Vision
> >>>
> >>> Keith will be doing an Unconference session on the Workflow Service
> >>> idea? I believe on Wednesday afternoon.
> >>>
> >>> Thanks,
> >>>
> >>> Adrian
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
>
> ------------------------------
>
> Message: 21
> Date: Wed, 17 Apr 2013 15:13:55 -0700
> From: Duncan Johnston Watt <duncan.johnstonwatt at cloudsoftcorp.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Heat/DSL2
> Message-ID:
> <CABoR60Ljx6yTkdAsEzaJPEkpf8rb4wqwn-2FM-uY=
> y+4w8zGQQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Travis
>
> Hi. The lightning talks happened over lunchtime today.
>
> However there is an unconference session led by Alex covering this material
> at 2.20PM Thursday in A104.
>
> Because there was a glitch with the AV during one of the lightning talks
> (Adrian Otto/Anish Karmarker's talk on OASIS CAMP) this will be repeated at
> the start of the unconference session.
>
> Best
>
> Duncan
>
> On 17 April 2013 14:37, Tripp, Travis S <travis.tripp at hp.com> wrote:
>
> > Alex,
> >
> > When are the lightning talks?
> >
> > Travis
> >
> > -----Original Message-----
> > From: Alex Heneveld [mailto:alex.heneveld at cloudsoftcorp.com]
> > Sent: Wednesday, April 17, 2013 12:56 PM
> > To: OpenStack Development Mailing List
> > Subject: [openstack-dev] Heat/DSL2
> >
> >
> > I've been working through the Heat/DSL [1] idea, trying to whittle it
> down
> > to an even simpler model, suitable as an abstraction atop CloudFormation
> as
> > well as TOSCA and CAMP. And like [1] trying to make it easy for mortals
> to
> > read and write.
> >
> > The current state is at Heat/DSL2 [2], with a rough python parser
> > implementation (not connected to Heat yet) at [3].
> >
> > I'll be around today and tomorrow so if anyone would like to discuss F2F
> > or on IRC (alexheneveld) please shout.
> >
> > Also note there are some related lightning talks starting soon and an
> > unconference tomorrow at 2.20pm.
> >
> > Best
> > Alex
> >
> > [1] https://wiki.openstack.org/wiki/Heat/DSL
> > [2] https://wiki.openstack.org/wiki/Heat/DSL2
> > [3] https://github.com/sjcorbett/heat-camp-yaml
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Duncan Johnston-Watt
> CEO | Cloudsoft Corporation
>
> Twitter | @duncanjw
> Mobile | +44 777 190 2653
> Skype | duncan_johnstonwatt
> Linkedin | www.linkedin.com/in/duncanjohnstonwatt
>
> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>
> This e-mail message is confidential and for use by the addressee only. If
> the message is received by anyone other than the addressee, please return
> the message to the sender by replying to it and then delete the message
> from your computer. Internet e-mails are not necessarily secure. Cloudsoft
> Corporation Limited does not accept responsibility for changes made to this
> message after it was sent.
>
> Whilst all reasonable care has been taken to avoid the transmission of
> viruses, it is the responsibility of the recipient to ensure that the
> onward transmission, opening or use of this message and any attachments
> will not adversely affect its systems or data. No responsibility is
> accepted by Cloudsoft Corporation Limited in this regard and the recipient
> should carry out such virus and other checks as it considers appropriate.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/a526a13a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 22
> Date: Wed, 17 Apr 2013 23:10:18 +0000
> From: Adrian Otto <adrian.otto at rackspace.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> Message-ID: <2DDA2627-6224-441D-BEDD-784000AC3D1E at rackspace.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> Zane,
>
> On Apr 17, 2013, at 2:47 PM, Zane Bitter <zbitter at redhat.com>
> wrote:
>
> > Thanks Adrian!
> >
> > We should probably make it clear for those who can't be at Summit that
> this is not intended to be a record of the design summit discussions. I'd
> describe this as a snapshot of Adrian's evolving vision for Heat, taken
> after the design summit sessions.
>
> Good suggestion. I'll tune the text at the top of that wiki post to
> reflect that. I'd like to continue tweaking on this to give us something to
> aim toward. We absolutely will iterate toward it, and will start with
> something less ambitious. As we zero in to that, I'm happy to document that
> direction as well.
>
> > In particular, I think it reflects a couple of misconceptions about the
> current architecture of Heat, and it also contains some stuff that hasn't
> been discussed at all at Summit (e.g. the CEP part... btw my initial
> reaction to this is that it should probably talk to Ceilometer rather than
> the Autoscaling service).
>
> Yes, is that something we can talk about today or tomorrow while we are
> still together?
>
> > That said, there certainly *is* consensus that we want to evolve Heat
> toward being able to orchestrate whole applications rather than just
> services. We'll be doing further work throughout the week and subsequently
> on the mailing list to refine some of these architectural ideas, and we're
> looking forward to working with Adrian and his team at Rackspace to make it
> happen :)
>
> Thanks. I'd like to complement the whole Heat team. The collaborative
> spirit I have experienced while working with you has been terrific.
>
> Cheers,
>
> Adrian
>
> > cheers,
> > Zane.
> >
> > On 16/04/13 01:56, Adrian Otto wrote:
> >> Heaters,
> >>
> >> I attended the various sessions at the Design Summit today in Portland,
> and assembled as many of the ideas for future planning as I could. For the
> benefit of those who are not attending, or who were not in these sessions,
> I created this Wiki page to express what I think is an early consensus on
> where we could take things. Let's tweak this if it's not a good direction.
> >>
> >> https://wiki.openstack.org/wiki/Heat/Vision
> >>
> >> Keith will be doing an Unconference session on the Workflow Service
> idea? I believe on Wednesday afternoon.
> >>
> >> Thanks,
> >>
> >> Adrian
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 23
> Date: Wed, 17 Apr 2013 16:14:52 -0700
> From: Nachi Ueno <nachi at ntti3.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID:
> <
> CABJepwjnXRTAy7_urYSnwZNuzVW79qToWRp8YeVTLFUrZh-dxQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Kaiwei
>
> Thank you for your comment.
> It depends on the each VPNService sub class.
> Some L2VPNService may have network_id and association with out-of-path
> insertion mode.
> (This part is also not implemented)
> For some L3 VPN may support routed insertion mode, and the subclass of
> VPNService will have router_id (or port_id).
>
> The use of insertion mode is input value checking when we insert it.
>
> Thanks
> Nachi
>
>
>
> 2013/4/17 <fank at vmware.com>:
> > Hi Nachi,
> >
> > I'm not sure how "insertion_mode" could be any useful for plugins if it
> only indicate the mode as routed/out-of-path/floating insertion.
> >
> > For example, we need to associated it with a router if it is routed
> insertion (and we have an extension for associating a service with a router
> id:
> https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion).
> >
> > What we need for out-of-path insertion and floating insertion? A
> network/subnet id?
> >
> > -Kaiwei
> >
> > ----- Original Message -----
> > From: "Nachi Ueno" <nachi at ntti3.com>
> > To: "OpenStack Development Mailing List" <
> openstack-dev at lists.openstack.org>
> > Sent: Wednesday, April 17, 2013 11:42:38 AM
> > Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> discussion
> >
> > Hi folks
> >
> > May be, there are many ways to categorize use cases.
> >
> > We agreed we will model VPN as a Service instance (VPNService).
> > If we define new service, the service can support any kind of VPNs (L2,
> L3)
> > What's we need to be discussed is attributes of Generalize VPN Service
> > Models if we can have generic vpn service models.
> >
> > I added vpn map for slide 13 ( This may help this discussion)
> >
> https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310
> >
> > This is current proposed attributes.
> >
> > 1. id
> > 2. name
> > 3. tenant_id
> > 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... )
> > 5. insertion_mode
> > 6. mode = l2 | l3 ?
> >
> > I believe there is no need to discussion about 1-4.
> > 5 is needed to use service insertion.
> > ( Prevent routed service insertion of which didn't support it)
> >
> > 6. Mode
> > I'm not sure how to use this attribute, so I'm very appreciate if
> > someone would add
> > the motivation on the slide
> >
> > Thanks
> > Nachi
> >
> > 2013/4/17 Yi Yang <yyos1999 at gmail.com>:
> >> While quantum VPN can serve as either client or server or both, there
> are
> >> big difference on requirements -- for example, a SSL VPN server needs to
> >> have an address pool, which is not required for clients.
> >>
> >> IMO, we need to first differentiate these use cases (server vs. client)
> >> before we decide what state fields should be covered.
> >>
> >> Yi
> >>
> >>
> >> On 4/17/13 9:58 AM, Sachin Thakkar wrote:
> >>
> >> I definitely agree with point (1) from Yi below. There are so many
> flavors
> >> and intricacies to VPNs that it would be to our advantage to decouple as
> >> much as possible.
> >>
> >> For (2), my understanding is that the quantum VPN could be either. Is
> your
> >> comment to add this explicit role in addition to the state fields?
> >>
> >> Sachin
> >>
> >> ________________________________
> >> From: "Yi Yang" <yyos1999 at gmail.com>
> >> To: "OpenStack Development Mailing List" <
> openstack-dev at lists.openstack.org>
> >> Sent: Wednesday, April 17, 2013 12:42:35 AM
> >> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> >> discussion
> >>
> >> A couple of quick comments:
> >>
> >> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN cases,
> >> as the former adopts a server-client model while the latter doesn't.
> >>
> >> 2. One thing missed in these use cases, except in use case 3, is the
> >> "role" -- does the quantum VPN act as a server or a client?
> >>
> >> Yi
> >>
> >>
> >>
> >> On 4/16/13 8:16 PM, Nachi Ueno wrote:
> >>> Hi folks
> >>>
> >>> Thank you for joining today's discussion.
> >>> Based on today's discussion, we updated the slide.
> >>>
> >>>
> >>>
> https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
> >>>
> >>> Changes
> >>> - Simplify use case
> >>> removed any router references because it deals with implementation
> >>> - Simplify Generic VPNService model
> >>> removed any router references because it deals with service
> insertion
> >>> - Update attributes of generic VPN Service
> >>> Layer2 or Layer3 mode etc
> >>>
> >>> Tommorows' discussion is
> >>> 5:20 at OpenStack Networking room
> >>>
> >>>
> http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335acc8a78ff61c#.UW3p1SvC82g
> >>>
> >>> Thanks!
> >>> Nachi
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 24
> Date: Wed, 17 Apr 2013 23:40:34 +0000
> From: Alan Kavanagh <alan.kavanagh at ericsson.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID:
> <C977B257ADF8814C8EB4FB66BB9D0C2E0AB758 at eusaamb109.ericsson.se>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Nachi
>
> I think we have some big fundamental issues here. You may not require an
> insertion mode for some L2VPN types, depending on the service you want the
> L2VPN to offer. Yi also brings a really good point that I feel we are not
> reflecting and showing on routing, we should decouple routing completely
> from the VPN Service. Also you have two Router types, one to advertise the
> VPN Tunnel End Point Upstream for reachability and one if "you want
> dynamic routing" for a tenant network (for example) from one network site
> to another through the VPN Tunnel.
>
> I feel we are mixing a lot of these fundamental concepts and topics.
>
> Alan
>
> -----Original Message-----
> From: Nachi Ueno [mailto:nachi at ntti3.com]
> Sent: April-17-13 7:15 PM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> discussion
>
> Hi Kaiwei
>
> Thank you for your comment.
> It depends on the each VPNService sub class.
> Some L2VPNService may have network_id and association with out-of-path
> insertion mode.
> (This part is also not implemented)
> For some L3 VPN may support routed insertion mode, and the subclass of
> VPNService will have router_id (or port_id).
>
> The use of insertion mode is input value checking when we insert it.
>
> Thanks
> Nachi
>
>
>
> 2013/4/17 <fank at vmware.com>:
> > Hi Nachi,
> >
> > I'm not sure how "insertion_mode" could be any useful for plugins if it
> only indicate the mode as routed/out-of-path/floating insertion.
> >
> > For example, we need to associated it with a router if it is routed
> insertion (and we have an extension for associating a service with a router
> id:
> https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion).
> >
> > What we need for out-of-path insertion and floating insertion? A
> network/subnet id?
> >
> > -Kaiwei
> >
> > ----- Original Message -----
> > From: "Nachi Ueno" <nachi at ntti3.com>
> > To: "OpenStack Development Mailing List"
> > <openstack-dev at lists.openstack.org>
> > Sent: Wednesday, April 17, 2013 11:42:38 AM
> > Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> > today's discussion
> >
> > Hi folks
> >
> > May be, there are many ways to categorize use cases.
> >
> > We agreed we will model VPN as a Service instance (VPNService).
> > If we define new service, the service can support any kind of VPNs
> > (L2, L3) What's we need to be discussed is attributes of Generalize
> > VPN Service Models if we can have generic vpn service models.
> >
> > I added vpn map for slide 13 ( This may help this discussion)
> > https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c4
> > 7iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310
> >
> > This is current proposed attributes.
> >
> > 1. id
> > 2. name
> > 3. tenant_id
> > 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... ) 5. insertion_mode
> > 6. mode = l2 | l3 ?
> >
> > I believe there is no need to discussion about 1-4.
> > 5 is needed to use service insertion.
> > ( Prevent routed service insertion of which didn't support it)
> >
> > 6. Mode
> > I'm not sure how to use this attribute, so I'm very appreciate if
> > someone would add the motivation on the slide
> >
> > Thanks
> > Nachi
> >
> > 2013/4/17 Yi Yang <yyos1999 at gmail.com>:
> >> While quantum VPN can serve as either client or server or both, there
> >> are big difference on requirements -- for example, a SSL VPN server
> >> needs to have an address pool, which is not required for clients.
> >>
> >> IMO, we need to first differentiate these use cases (server vs.
> >> client) before we decide what state fields should be covered.
> >>
> >> Yi
> >>
> >>
> >> On 4/17/13 9:58 AM, Sachin Thakkar wrote:
> >>
> >> I definitely agree with point (1) from Yi below. There are so many
> >> flavors and intricacies to VPNs that it would be to our advantage to
> >> decouple as much as possible.
> >>
> >> For (2), my understanding is that the quantum VPN could be either. Is
> >> your comment to add this explicit role in addition to the state fields?
> >>
> >> Sachin
> >>
> >> ________________________________
> >> From: "Yi Yang" <yyos1999 at gmail.com>
> >> To: "OpenStack Development Mailing List"
> >> <openstack-dev at lists.openstack.org>
> >> Sent: Wednesday, April 17, 2013 12:42:35 AM
> >> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> >> today's discussion
> >>
> >> A couple of quick comments:
> >>
> >> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN
> >> cases, as the former adopts a server-client model while the latter
> doesn't.
> >>
> >> 2. One thing missed in these use cases, except in use case 3, is the
> >> "role" -- does the quantum VPN act as a server or a client?
> >>
> >> Yi
> >>
> >>
> >>
> >> On 4/16/13 8:16 PM, Nachi Ueno wrote:
> >>> Hi folks
> >>>
> >>> Thank you for joining today's discussion.
> >>> Based on today's discussion, we updated the slide.
> >>>
> >>>
> >>> https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZ
> >>> n7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
> >>>
> >>> Changes
> >>> - Simplify use case
> >>> removed any router references because it deals with
> >>> implementation
> >>> - Simplify Generic VPNService model
> >>> removed any router references because it deals with service
> >>> insertion
> >>> - Update attributes of generic VPN Service
> >>> Layer2 or Layer3 mode etc
> >>>
> >>> Tommorows' discussion is
> >>> 5:20 at OpenStack Networking room
> >>>
> >>> http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335
> >>> acc8a78ff61c#.UW3p1SvC82g
> >>>
> >>> Thanks!
> >>> Nachi
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 25
> Date: Wed, 17 Apr 2013 17:02:19 -0700
> From: Nachi Ueno <nachi at ntti3.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> today's discussion
> Message-ID:
> <CABJepwi0DnmgpGy3FT3L=_K3i6utyuw9CU8_XML2FUAEfang=
> g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Alan
>
> It makes sence. so now, I'm +1 for removing insertion_mode.
>
>
> 2013/4/17 Alan Kavanagh <alan.kavanagh at ericsson.com>:
> > Hi Nachi
> >
> > I think we have some big fundamental issues here. You may not require an
> insertion mode for some L2VPN types, depending on the service you want the
> L2VPN to offer. Yi also brings a really good point that I feel we are not
> reflecting and showing on routing, we should decouple routing completely
> from the VPN Service. Also you have two Router types, one to advertise the
> VPN Tunnel End Point Upstream for reachability and one if "you want
> dynamic routing" for a tenant network (for example) from one network site
> to another through the VPN Tunnel.
> >
> > I feel we are mixing a lot of these fundamental concepts and topics.
> >
> > Alan
> >
> > -----Original Message-----
> > From: Nachi Ueno [mailto:nachi at ntti3.com]
> > Sent: April-17-13 7:15 PM
> > To: OpenStack Development Mailing List
> > Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's
> discussion
> >
> > Hi Kaiwei
> >
> > Thank you for your comment.
> > It depends on the each VPNService sub class.
> > Some L2VPNService may have network_id and association with out-of-path
> insertion mode.
> > (This part is also not implemented)
> > For some L3 VPN may support routed insertion mode, and the subclass of
> VPNService will have router_id (or port_id).
> >
> > The use of insertion mode is input value checking when we insert it.
> >
> > Thanks
> > Nachi
> >
> >
> >
> > 2013/4/17 <fank at vmware.com>:
> >> Hi Nachi,
> >>
> >> I'm not sure how "insertion_mode" could be any useful for plugins if it
> only indicate the mode as routed/out-of-path/floating insertion.
> >>
> >> For example, we need to associated it with a router if it is routed
> insertion (and we have an extension for associating a service with a router
> id:
> https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion).
> >>
> >> What we need for out-of-path insertion and floating insertion? A
> network/subnet id?
> >>
> >> -Kaiwei
> >>
> >> ----- Original Message -----
> >> From: "Nachi Ueno" <nachi at ntti3.com>
> >> To: "OpenStack Development Mailing List"
> >> <openstack-dev at lists.openstack.org>
> >> Sent: Wednesday, April 17, 2013 11:42:38 AM
> >> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> >> today's discussion
> >>
> >> Hi folks
> >>
> >> May be, there are many ways to categorize use cases.
> >>
> >> We agreed we will model VPN as a Service instance (VPNService).
> >> If we define new service, the service can support any kind of VPNs
> >> (L2, L3) What's we need to be discussed is attributes of Generalize
> >> VPN Service Models if we can have generic vpn service models.
> >>
> >> I added vpn map for slide 13 ( This may help this discussion)
> >> https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c4
> >> 7iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310
> >>
> >> This is current proposed attributes.
> >>
> >> 1. id
> >> 2. name
> >> 3. tenant_id
> >> 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... ) 5. insertion_mode
> >> 6. mode = l2 | l3 ?
> >>
> >> I believe there is no need to discussion about 1-4.
> >> 5 is needed to use service insertion.
> >> ( Prevent routed service insertion of which didn't support it)
> >>
> >> 6. Mode
> >> I'm not sure how to use this attribute, so I'm very appreciate if
> >> someone would add the motivation on the slide
> >>
> >> Thanks
> >> Nachi
> >>
> >> 2013/4/17 Yi Yang <yyos1999 at gmail.com>:
> >>> While quantum VPN can serve as either client or server or both, there
> >>> are big difference on requirements -- for example, a SSL VPN server
> >>> needs to have an address pool, which is not required for clients.
> >>>
> >>> IMO, we need to first differentiate these use cases (server vs.
> >>> client) before we decide what state fields should be covered.
> >>>
> >>> Yi
> >>>
> >>>
> >>> On 4/17/13 9:58 AM, Sachin Thakkar wrote:
> >>>
> >>> I definitely agree with point (1) from Yi below. There are so many
> >>> flavors and intricacies to VPNs that it would be to our advantage to
> >>> decouple as much as possible.
> >>>
> >>> For (2), my understanding is that the quantum VPN could be either. Is
> >>> your comment to add this explicit role in addition to the state fields?
> >>>
> >>> Sachin
> >>>
> >>> ________________________________
> >>> From: "Yi Yang" <yyos1999 at gmail.com>
> >>> To: "OpenStack Development Mailing List"
> >>> <openstack-dev at lists.openstack.org>
> >>> Sent: Wednesday, April 17, 2013 12:42:35 AM
> >>> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from
> >>> today's discussion
> >>>
> >>> A couple of quick comments:
> >>>
> >>> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN
> >>> cases, as the former adopts a server-client model while the latter
> doesn't.
> >>>
> >>> 2. One thing missed in these use cases, except in use case 3, is the
> >>> "role" -- does the quantum VPN act as a server or a client?
> >>>
> >>> Yi
> >>>
> >>>
> >>>
> >>> On 4/16/13 8:16 PM, Nachi Ueno wrote:
> >>>> Hi folks
> >>>>
> >>>> Thank you for joining today's discussion.
> >>>> Based on today's discussion, we updated the slide.
> >>>>
> >>>>
> >>>> https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZ
> >>>> n7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
> >>>>
> >>>> Changes
> >>>> - Simplify use case
> >>>> removed any router references because it deals with
> >>>> implementation
> >>>> - Simplify Generic VPNService model
> >>>> removed any router references because it deals with service
> >>>> insertion
> >>>> - Update attributes of generic VPN Service
> >>>> Layer2 or Layer3 mode etc
> >>>>
> >>>> Tommorows' discussion is
> >>>> 5:20 at OpenStack Networking room
> >>>>
> >>>> http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335
> >>>> acc8a78ff61c#.UW3p1SvC82g
> >>>>
> >>>> Thanks!
> >>>> Nachi
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 26
> Date: Wed, 17 Apr 2013 17:16:31 -0700
> From: Roshan <roshanagr at gmail.com>
> To: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] Workflow as a service: Convection
> Message-ID: <D8BE48D3-70FC-4912-ADFA-DF384AEE4730 at gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Here are the etherpad notes from today 's session on workflow. Feel free
> to add/ modify what I missed
>
> https://etherpad.openstack.org/Convection
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130417/b5ecd1d8/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 27
> Date: Thu, 18 Apr 2013 04:02:29 +0300
> From: Avishay Traeger <AVISHAY at il.ibm.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] AUTO: Avishay Traeger is out of the office
> (returning 05/12/2013)
> Message-ID:
> <
> OF776DC00D.EB3946DF-ONC2257B51.0005B8AE-C2257B51.0005B8AE at il.ibm.com>
> Content-Type: text/plain; charset=US-ASCII
>
>
> I am out of the office until 05/12/2013.
>
> For technical issues regarding the Storwize/SVC Cinder driver, please
> contact: Jie Ping Wu <wujp at cn.ibm.com>, Li Min Liu <liminliu at cn.ibm.com>,
> Ronen Kat <ronenkat at il.ibm.com>
> For all other issue, please contact my manager, Dalit Naor
> <dalit at il.ibm.com>
>
>
> Note: This is an automated response to your message "Re: [openstack-dev]
> Heat/DSL2" sent on 18/04/2013 0:37:28.
>
> This is the only notification you will receive while this person is away.
>
>
>
>
> ------------------------------
>
> Message: 28
> Date: Thu, 18 Apr 2013 10:36:00 +0800
> From: Shake Chen <shake.chen at gmail.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] vms come up on a different bridge..
> Message-ID:
> <CAO__-NbXdvhV20L_0vamg_aGpECf06ypdY-j=
> 5a6zhq27a1cAg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Prashanth
>
> whether can share your netwrok interface setting /etc/netwrok/interface.
>
> I am not sure the setting .
>
> physical_interface_mappings = physnet2:eth2
>
>
> what I need to setting in eth2?
>
>
> On Wed, Apr 17, 2013 at 11:38 PM, Prashanth Prahalad <
> prashanth.prahal at gmail.com> wrote:
>
> > Hi Folks,
> >
> > I'm setting up quantum with linux bridge. I might have configured this
> > incorrectly and looking for some help on what could be going on.
> >
> > This is my quantum.conf and linuxbridge_conf.ini - which tries to setup
> > the linux bridge over eth2.
> >
> > [DEFAULT]
> > auth_strategy = keystone
> > allow_overlapping_ips = True
> > policy_file = /etc/quantum/policy.json
> > debug = True
> > verbose = True
> > service_plugins =
> > quantum.plugins.services.agent_loadbalancer.plugin.LoadBalancerPlugin
> > core_plugin =
> > quantum.plugins.linuxbridge.lb_quantum_plugin.LinuxBridgePluginV2
> > rabbit_password = openstack
> > rabbit_host = localhost
> > rpc_backend = quantum.openstack.common.rpc.impl_kombu
> > state_path = /opt/stack/data/quantum
> > debug = True
> > verbose = True
> > lock_path = $state_path/lock
> > log_file = quantum.log
> > log_dir = /var/log/quantum
> > bind_host = 0.0.0.0
> > bind_port = 9696
> > <......>
> >
> > linuxbridge_conf.ini
> >
> > [VLANS]
> > tenant_network_type = vlan
> > network_vlan_ranges = physnet2:1000:2999
> > [DATABASE]
> > sql_connection = mysql://root:openstack@localhost
> > /quantum_linux_bridge?charset=utf8
> > reconnect_interval = 2
> > [LINUX_BRIDGE]
> > physical_interface_mappings = physnet2:eth2
> > [AGENT]
> > root_helper = sudo /usr/local/bin/quantum-rootwrap
> > /etc/quantum/rootwrap.conf
> > polling_interval = 2
> > [SECURITYGROUP]
> > firewall_driver =
> > quantum.agent.linux.iptables_firewall.IptablesFirewallDriver
> >
> > But when the VM is booted up, it comes up over brq3c2d19b3-fa instead of
> > br-eth2
> >
> > bridge name bridge id STP enabled interfaces
> > br-eth2 8000.000cfc01f473 no eth2
> > brq057a0be8-e9 8000.96f0115f0c03 no
> > tapa0dcbf6a-73
> > brq34f87736-91 8000.32245b5d90b7 no
> > tap22c7ffb1-9f
> >
> > tap874fecfb-ac
> > brq3c2d19b3-fa 8000.3a84ed127b7a no
> > tapadbf1b11-e9
> >
> > tapc6c54b78-87
> >
> > tapcf424b48-54
> >
> > tapdb58671d-bd
> >
> > tapdb661e2b-ff
> >
> > Here's a list of commands :
> >
> > quantum net-create sharednet1 --shared --provider:network_type=flat -
> > provider:physical_network=physnet2
> > quantum subnet-create sharednet1 30.0.0.0/24
> >
> >
> >
> +--------------------------------------+------------+------------------------------------------------------+
> > | id | name | subnets
> > |
> >
> >
> +--------------------------------------+------------+------------------------------------------------------+
> > | 057a0be8-e9f9-4e23-a97b-08d2bdb67ad2 | public |
> > 92b32336-76d2-4fa3-a5eb-e1a4b76c648c 172.24.4.224/28 |
> > | 34f87736-91d6-4f00-ad11-fe39e76638ce | private |
> > f315bfd5-5f8a-4fa4-bca2-0814998cf8d5 10.0.0.0/24 |
> > | 3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 | sharednet1 |
> > 4691c3ca-b769-4454-9997-1b4dd851d602 30.0.0.0/24 |
> >
> >
> +--------------------------------------+------------+------------------------------------------------------+
> >
> > nova boot --image cirros --flavor m1.tiny --nic
> > net-id=3c2d19b3-fa72-4bcb-916b-8d54e0e879b1 --key-name test
> my_first_server
> >
> > Anything I'm missing ?
> >
> > Thanks !
> > Prashanth
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>
>
> --
> Shake Chen
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/bb6ebd36/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 29
> Date: Wed, 17 Apr 2013 21:53:18 -0700
> From: Nachi Ueno <nachi at ntti3.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Quantum] Quantum VPN discussion
> Message-ID:
> <CABJepwhOF7pLwJfuwk9=t=
> YD5ZCUSosrQi2hdZDAZuDk5b8CHw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> HI folks
>
> Thank you for your joining today's Quantum VPN discussion.
>
> - We will add more detailed usecases
> - remove insertion from GeneralVPNService
> - continue discussion for needs of mode (l2 or l3) attribute of
> GeneralVPNService
> -- The opinion for removing mode
> GeneralVPNService has type attribute, so type can also express l2 or l3.
> For example, l2.l2tp l3.bgpmpls kind of thing can be used.
> if there are no strong support for using mode, we will remote the
> attribute
> - At first, we will focus on nova-parity SSL-VPN support ( Swami or
> Sachin will work on this)
> Write ssl-vpn usecase
> Write API spec
> discuss it
> - milestone could be
> general model -> H1
> ssl-vpn -> H1/H2
> the others -> H2/H3
>
> Thanks!
> Nachi
>
>
>
> ------------------------------
>
> Message: 30
> Date: Thu, 18 Apr 2013 05:37:02 +0000
> From: Joshua Harlow <harlowja at yahoo-inc.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>, Zane Bitter <
> zbitter at redhat.com>
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> Message-ID: <CD94D2C5.3A5A9%harlowja at yahoo-inc.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> I'd be very interested in having 'Scheduler & Workflow Service' part there
> be a library.
>
> Pretty much every application is a workflow in some way, and using said
> library in nova for the orc work there would be very neat.
>
> As long as it doesn't change the use-case that heat desires of course (or
> overload that use-case and make everything complex when it doesn't need to
> be)...
>
> It would be very neat to use those 2 services as a library, where I can
> submit arbitrary code to (the state transitions that nova does) and have
> it handle calling those states, coordinating, rolling back (or at least
> calling a method to rollback, since rollback is usually very specific to
> what has occurred). Basically submitting jobs, but not via a DSL/CEP (or
> the like), not via a model interpreter, but directly via code. Is there
> any documentation on how heat handles task resumption (if 1 engine fails,
> another should be able to continue the work), how are said engines made HA
> and reliable...
>
> Such a engine library would make sense as the core 'engine' for a lot of
> the openstack core projects imho.
>
> Thoughts?
>
> On 4/17/13 2:47 PM, "Zane Bitter" <zbitter at redhat.com> wrote:
>
> >Thanks Adrian!
> >
> >We should probably make it clear for those who can't be at Summit that
> >this is not intended to be a record of the design summit discussions.
> >I'd describe this as a snapshot of Adrian's evolving vision for Heat,
> >taken after the design summit sessions. In particular, I think it
> >reflects a couple of misconceptions about the current architecture of
> >Heat, and it also contains some stuff that hasn't been discussed at all
> >at Summit (e.g. the CEP part... btw my initial reaction to this is that
> >it should probably talk to Ceilometer rather than the Autoscaling
> >service).
> >
> >That said, there certainly *is* consensus that we want to evolve Heat
> >toward being able to orchestrate whole applications rather than just
> >services. We'll be doing further work throughout the week and
> >subsequently on the mailing list to refine some of these architectural
> >ideas, and we're looking forward to working with Adrian and his team at
> >Rackspace to make it happen :)
> >
> >cheers,
> >Zane.
> >
> >On 16/04/13 01:56, Adrian Otto wrote:
> >> Heaters,
> >>
> >> I attended the various sessions at the Design Summit today in Portland,
> >>and assembled as many of the ideas for future planning as I could. For
> >>the benefit of those who are not attending, or who were not in these
> >>sessions, I created this Wiki page to express what I think is an early
> >>consensus on where we could take things. Let's tweak this if it's not a
> >>good direction.
> >>
> >> https://wiki.openstack.org/wiki/Heat/Vision
> >>
> >> Keith will be doing an Unconference session on the Workflow Service
> >>idea? I believe on Wednesday afternoon.
> >>
> >> Thanks,
> >>
> >> Adrian
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 31
> Date: Thu, 18 Apr 2013 06:48:57 +0000
> From: "Bhandaru, Malini K" <malini.k.bhandaru at intel.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] passwords in logs --security related
> Message-ID:
> <
> EE6FFF4F6C34C84C8C98DD2414EEA47E53C42372 at ORSMSX154.amr.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello All!
>
> David Geng is addressing a case of password logging in keystone. Do we
> handle any passwords in other openstack
> components and log them? Might they benefit from David moving his fix
> into Oslo as a log filter (a nice suggestion from Guang-yee).
> Please weigh in. If yes, what is expected the string pattern?
>
> https://review.openstack.org/#/c/26487/
>
>
> Regards
> Malini
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/33bcf398/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 32
> Date: Thu, 18 Apr 2013 07:19:52 +0000
> From: Adrian Otto <adrian.otto at rackspace.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> Message-ID: <3FF04A18-D419-448B-A5D0-E2812C98F7F2 at rackspace.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> Joshua,
>
> On Apr 17, 2013, at 10:37 PM, Joshua Harlow <harlowja at yahoo-inc.com>
> wrote:
>
> > I'd be very interested in having 'Scheduler & Workflow Service' part
> there
> > be a library.
> >
> > Pretty much every application is a workflow in some way, and using said
> > library in nova for the orc work there would be very neat.
>
> We had an unconference session today when we discussed this concept:
>
> https://wiki.openstack.org/wiki/Convection
>
> The idea is that this could start as a library in Heat, and then be moved
> to Oslo upon achievement of a reasonable level of maturity.
>
> > As long as it doesn't change the use-case that heat desires of course (or
> > overload that use-case and make everything complex when it doesn't need
> to
> > be)?
>
> It should actually simplify Heat.
>
> > It would be very neat to use those 2 services as a library, where I can
> > submit arbitrary code to (the state transitions that nova does) and have
> > it handle calling those states, coordinating, rolling back (or at least
> > calling a method to rollback, since rollback is usually very specific to
> > what has occurred). Basically submitting jobs, but not via a DSL/CEP (or
> > the like), not via a model interpreter, but directly via code. Is there
> > any documentation on how heat handles task resumption (if 1 engine fails,
> > another should be able to continue the work), how are said engines made
> HA
> > and reliable?
>
> At the very least, we should expect a solution that will allow you to
> submit a callback in some form (possibly a web hook, or a function) so that
> you can act upon state transitions in the workflow. There are ways to deal
> with rollback. Chances are that a rather simple early implementation would
> shift that to the client, but there are way to deal with it in the service
> too.
>
> > Such a engine library would make sense as the core 'engine' for a lot of
> > the openstack core projects imho.
>
> Yes, if the vision is achieved, you would use Heat for Orchestration
> purposes, and Convection for simple task executions. The first use case for
> Convection would be a task that has a start, a sequence of tasks, followed
> by a termination. This could be very useful in Nova when you care about
> kicking off a workflow and be able to get a callback upon completion of the
> job/task.
>
> For jobs that would benefit from parallel execution and coordination of
> multiple tasks, you would use Heat as an Orchestration instrument, which
> would in turn use multiple workflows.
>
> > Thoughts?
>
> The first implementation is likely to be library within the Heat project
> that the Heat engine uses. Next, an Oslo library, and then a standalone
> service with a REST API that uses the Oslo library for general purpose uses
> from applications outside Openstack, perhaps those deployed by Heat, etc.
> This gives us the opportunity to offer the service in an fault tolerant HA
> configuration for use cases that require reliable workflow execution. If
> you are interested in contributing, I urge you to connect with Keith Bray <
> keith.bray at racksopace.com> to coordinate efforts.
>
> Cheers,
>
> Adrian
>
> >
> > On 4/17/13 2:47 PM, "Zane Bitter" <zbitter at redhat.com> wrote:
> >
> >> Thanks Adrian!
> >>
> >> We should probably make it clear for those who can't be at Summit that
> >> this is not intended to be a record of the design summit discussions.
> >> I'd describe this as a snapshot of Adrian's evolving vision for Heat,
> >> taken after the design summit sessions. In particular, I think it
> >> reflects a couple of misconceptions about the current architecture of
> >> Heat, and it also contains some stuff that hasn't been discussed at all
> >> at Summit (e.g. the CEP part... btw my initial reaction to this is that
> >> it should probably talk to Ceilometer rather than the Autoscaling
> >> service).
> >>
> >> That said, there certainly *is* consensus that we want to evolve Heat
> >> toward being able to orchestrate whole applications rather than just
> >> services. We'll be doing further work throughout the week and
> >> subsequently on the mailing list to refine some of these architectural
> >> ideas, and we're looking forward to working with Adrian and his team at
> >> Rackspace to make it happen :)
> >>
> >> cheers,
> >> Zane.
> >>
> >> On 16/04/13 01:56, Adrian Otto wrote:
> >>> Heaters,
> >>>
> >>> I attended the various sessions at the Design Summit today in Portland,
> >>> and assembled as many of the ideas for future planning as I could. For
> >>> the benefit of those who are not attending, or who were not in these
> >>> sessions, I created this Wiki page to express what I think is an early
> >>> consensus on where we could take things. Let's tweak this if it's not a
> >>> good direction.
> >>>
> >>> https://wiki.openstack.org/wiki/Heat/Vision
> >>>
> >>> Keith will be doing an Unconference session on the Workflow Service
> >>> idea? I believe on Wednesday afternoon.
> >>>
> >>> Thanks,
> >>>
> >>> Adrian
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 33
> Date: Thu, 18 Apr 2013 08:47:10 +0000
> From: Matt Van Winkle <mvanwink at rackspace.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Cc: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] passwords in logs --security related
> Message-ID: <BB3E33C3-8295-40D7-B4D0-135643F20E9E at rackspace.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Honestly, no passwords should be logged anywhere. We need to be able to
> expose logs in a way that doesn't provide a feat platform for
> non-privileged users to script athentication against
>
> Sent from my iPhone
>
> On Apr 17, 2013, at 11:58 PM, "Bhandaru, Malini K" <
> malini.k.bhandaru at intel.com<mailto:malini.k.bhandaru at intel.com>> wrote:
>
> Hello All!
>
> David Geng is addressing a case of password logging in keystone. Do we
> handle any passwords in other openstack
> components and log them? Might they benefit from David moving his fix
> into Oslo as a log filter (a nice suggestion from Guang-yee).
> Please weigh in. If yes, what is expected the string pattern?
>
> https://review.openstack.org/#/c/26487/
>
>
> Regards
> Malini
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at 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/20130418/33f54f3d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 34
> Date: Thu, 18 Apr 2013 08:50:15 +0000
> From: Matt Van Winkle <mvanwink at rackspace.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Cc: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] passwords in logs --security related
> Message-ID: <B3D315D8-2914-4E1F-9CBF-EE4FAD9A8DE5 at rackspace.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Summit + late night + big thumbs = fail
>
>
>
> Sent from my iPhone
>
> On Apr 18, 2013, at 1:47 AM, "Matt Van Winkle" <mvanwink at rackspace.com
> <mailto:mvanwink at rackspace.com>> wrote:
>
> Honestly, no passwords should be logged anywhere. We need to be able to
> expose logs in a way that doesn't provide a feat platform for
> non-privileged users to script athentication against
>
> Sent from my iPhone
>
> On Apr 17, 2013, at 11:58 PM, "Bhandaru, Malini K" <
> malini.k.bhandaru at intel.com<mailto:malini.k.bhandaru at intel.com>> wrote:
>
> Hello All!
>
> David Geng is addressing a case of password logging in keystone. Do we
> handle any passwords in other openstack
> components and log them? Might they benefit from David moving his fix
> into Oslo as a log filter (a nice suggestion from Guang-yee).
> Please weigh in. If yes, what is expected the string pattern?
>
> https://review.openstack.org/#/c/26487/
>
>
> Regards
> Malini
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at 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/20130418/64188223/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 35
> Date: Thu, 18 Apr 2013 11:00:50 +0200
> From: Yann Fouillat <yann.fouillat.ext at makina-corpus.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [Cinder] Raised exception in utils.execute
> Message-ID: <516FB642.10902 at makina-corpus.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> I had the same problem as
> https://lists.launchpad.net/openstack/msg20619.html. For information,
> here is the traceback of my error:
>
> =====================================================================
> Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 224,
> in _start_child
> self._child_process(wrap.server)
> File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 201,
> in _child_process
> launcher.run_server(server)
> File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 95,
> in run_server
> server.start()
> File "/usr/lib/python2.7/dist-packages/cinder/service.py", line 342,
> in start
> self.manager.init_host()
> File "/usr/lib/python2.7/dist-packages/cinder/volume/manager.py",
> line 149, in init_host
> self.driver.ensure_export(ctxt, volume)
> File
> "/usr/lib/python2.7/dist-packages/cinder/volume/drivers/lvm.py", line
> 388, in ensure_export
> old_name=old_name)
> File "/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py", line
> 225, in create_iscsi_target
> self._new_target(name, tid, **kwargs)
> File "/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py", line
> 284, in _new_target
> **kwargs)
> File "/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py", line
> 73, in _run
> self._execute(self._cmd, *args, run_as_root=True, **kwargs)
> File "/usr/lib/python2.7/dist-packages/cinder/utils.py", line 145,
> in execute
> 'to utils.execute: %r') % kwargs)
> Error: Got unknown keyword args to utils.execute: {'old_name': None}
> =====================================================================
>
> I am not sure how to reproduce this behaviour. For info, I followed
> this guide to install OpenStack:
>
> https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_MultiNode/OpenStack_Grizzly_Install_Guide.rst
> .
> Maybe adding a volume in horizon and then restarting cinder-volume is
> enough to reproduce it.
>
> I figured out that the correction of this bug:
> https://bugs.launchpad.net/cinder/+bug/1065702 added an entry to
> kwargs which will last until utils.execute is called, in which an
> exception will be raised because old_name is not an expected parameter:
>
> =====================================================================
> if len(kwargs):
> raise exception.Error(_('Got unknown keyword args '
>
> 'to utils.execute: %r') % kwargs)
> =====================================================================
>
> So, my question is the following: is this exception really necessary ?
> kwargs is not used afterwards. Isn't logging a warning enough ? It
> would prevent this kind of unexpected behaviour withouwor
> t having to sanitize kwargs before each call of utils.execute.
>
> However, if there is really a reason to raise this exception, I'll be
> curious to know it.
>
> Regards,
>
> Yann
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRb7ZCAAoJEO1YhKM5jgEdOqgIALH3UWKK3oN1Pq9tTqPbNZ17
> 8F+8xID3DDDetIIIYvwaMuJ6ZMudjQXVXNYSkl9QH4s11qOawl72nxrQEgXdMkVE
> 1W2a+YttaVVDCwmw8yb4ikvL9tsuXu/P6xMkCASkUJ/f9UfSrxgr+6ElXCBEjIN0
> gtxxGTWYKfu94SSUVP8GLoOr4Vz7+DWmVf0qDG2fo8ZEV2Lz9HkWtkeJYQo3vre6
> fbJEI9WSiN55ajEB0suzH76yrWNnECNa90Xg5GTZuWOfEReA8D9ZBGfC5pjhvx8z
> nUs010B7X+5fKd5GA5VxotS1cg0eyLDdp55ZAE/zZh2eFyZvRKOtTMXV95pFeqU=
> =UaX0
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 36
> Date: Thu, 18 Apr 2013 09:10:04 +0000
> From: Adrian Otto <adrian.otto at rackspace.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> Message-ID: <D3206B2D-D31B-42B4-A371-FB39A5BA4AB4 at rackspace.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> I have further refined the Vision Wiki page in accordance with further
> feedback from the core team. This is a shorter term vision that more
> closely matches what we will evolve toward in the short therm.
>
> https://wiki.openstack.org/wiki/Heat/Vision
>
> On Apr 17, 2013, at 2:53 PM, Zane Bitter <zbitter at redhat.com> wrote:
>
> > On 16/04/13 09:05, Thomas Spatzier wrote:
> >> Hi Adrian,
> >>
> >> Adrian Otto <adrian.otto at rackspace.com> wrote on 16.04.2013 17:24:56:
> >>> From: Adrian Otto <adrian.otto at rackspace.com>
> >>> To: OpenStack Development Mailing List
> >> <openstack-dev at lists.openstack.org>,
> >>> Date: 16.04.2013 17:26
> >>> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> >>>
> >>> Thanks Thomas. Good point.
> >>>
> >>> In that case, wwe could just consider the one within the blue area
> >>> to have the label "Parser" and that should clarify matters. I'm
> >>> happy to make tweaks to clarify it.
> >>
> >> Maybe we can also come up with a better term than "parser". Would be
> >> interested what the Heat core team thinks.
> >
> > For historical reasons, "parser" is the name of the module that
> essentially runs the Heat orchestration engine. It's a terrible name that
> doesn't really reflect what it actually does, so I'm definitely in favour
> of changing it.
> >
> > This diagram is also showing it in the wrong place, so we have some more
> work to do to figure out some better terminology and get everyone on the
> same page.
> >
> > cheers,
> > Zane.
> >
> >>
> >> Regards,
> >> Thomas
> >>
> >>>
> >>> Adrian
> >>>
> >>>
> >>> -----Original message-----
> >>> From: Thomas Spatzier <thomas.spatzier at de.ibm.com>
> >>> To: OpenStack Development Mailing List
> >> <openstack-dev at lists.openstack.org>
> >>> Sent: Tue, Apr 16, 2013 14:22:07 GMT+00:00
> >>> Subject: Re: [openstack-dev] [Heat] Future Vision for Heat
> >>
> >>> Hi Adrian,
> >>>
> >>> thanks for taking writing this up to capture yesterday's discussions.
> >>> I don't fully understand what the difference or overlap of the Model
> >>> Interpreter inside the main blue box and the Model Interpreter in the
> >> green
> >>> box is. My understanding was that a Model Interpreter would be
> something
> >>> that translates an external format (such as CFN, TOSCA, whatever) to
> the
> >>> core Heat DSL. And then there would be one component which looks at the
> >>> common DSL model to derive the deployment plan (I think somebody said
> >> this
> >>> is what the "parser" does today).
> >>> I think having to partly re-implement the interpreter (in the sense of
> >>> compiling a concrete deployment plan directly) for various external
> >> formats
> >>> could be complicated.
> >>>
> >>> Adrian Otto <adrian.otto at rackspace.com> wrote on 16.04.2013 10:56:23:
> >>>
> >>>> From: Adrian Otto <adrian.otto at rackspace.com>
> >>>> To: OpenStack Development Mailing List
> >>> <openstack-dev at lists.openstack.org>,
> >>>> Date: 16.04.2013 10:57
> >>>> Subject: [openstack-dev] [Heat] Future Vision for Heat
> >>>>
> >>>> Heaters,
> >>>>
> >>>> I attended the various sessions at the Design Summit today in
> >>>> Portland, and assembled as many of the ideas for future planning as
> >>>> I could. For the benefit of those who are not attending, or who
> >>>> were not in these sessions, I created this Wiki page to express what
> >>>> I think is an early consensus on where we could take things. Let's
> >>>> tweak this if it's not a good direction.
> >>>>
> >>>> https://wiki.openstack.org/wiki/Heat/Vision
> >>>>
> >>>> Keith will be doing an Unconference session on the Workflow Service
> >>>> idea? I believe on Wednesday afternoon.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Adrian
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> End of OpenStack-dev Digest, Vol 12, Issue 22
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/143072ec/attachment-0001.html>
More information about the OpenStack-dev
mailing list