Re: [openstack-dev] [tacker] Core team changes / proposing Dharmendra Kushwaha

[Bharath Thiruveedula]

+1 for both.

Regards

Bharath T
Imaginea Technologies Inc.

On Wed, Jan 25, 2017 at 8:19 PM, HADDLETON, Robert W (Bob) <
bob.haddle...@nokia.com> wrote:

> +1
>
> Thanks Stephen!  And welcome aboard Dharmendra!
>
> Bob
>
>
> On 1/24/2017 6:58 PM, Sridhar Ramaswamy wrote:
>
>> Tackers,
>>
>> I'd like to propose following changes to the Tacker core team.
>>
>> Stephen Wong
>>
>> After being associated with Tacker project from its genesis, Stephen
>> Wong (irc: s3wong) has decided to step down from the core-team. I
>> would like to thank Stephen for his contribution to Tacker,
>> particularly for his help navigating the initial days splitting off
>> Neutron and in re-launching this project in Vancouver summit for
>> TOSCA-based NFV Orchestration. His recent effort in writing the SFC
>> driver to support VNF Forwarding Graph is much appreciated. Thanks
>> Stephen!
>>
>> Dharmendra Kushwaha
>>
>> It gives me great pleasure to propose Dharmendra (irc:  dkushwaha) to
>> join the Tacker core team. Dharmendra's contributions to tacker
>> started in Jan 2016. He is an active contributor across the board [1]
>> in bug fixes, code cleanups and, most recently, as a lead author of
>> the Network Services Descriptor blueprint.
>>
>> Also, Dharmendra recently stepped up to take care of bug triage for
>> Tacker. There is an uptick in deployment issues reported through LP
>> [2] and in irc - which itself is a good healthy thing. Now we need to
>> respond by fixing the issues reported promptly. Dharmendra’s help will
>> be immensely valuable here.
>>
>> Existing cores - please vote +1 / -1.
>>
>> thanks,
>> Sridhar
>>
>> [1] http://stackalytics.com/?module=tacker-group_id=dharmen
>> dra-kushwaha=marks
>> [2] https://answers.launchpad.net/tacker
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tacker] Abstract interface for VNFC

[bharath thiruveedula]

Hi Tackers,
As per this week meeting logs, regarding VNFC BP, I came to know that we need 
to add abstract interface which is invoked  by infra_driver. But as we decided 
to go with SoftwareDeployment option  in this cycle, most of the heat template 
changes are done by heat translator [1]. I couldn't understand the exact usage 
of VNFC abstract interface in this case. I think we have two options if we want 
to have abstract interface with SoftwareDeployment option.
1)Remove the VNFC part from tosca and give the rest as input to heat-translator 
and create the heat stack. In the "SoftwareDeployment" driver which implements 
the abstract interface we can add the corresponding heat resources for VNFC to 
the heat template and update the stack.
2)Just add the abstract interface as a place holder in this cycle. And 
implement it in the further cycles(which may not sounds good)
Let me know your suggestion.
[1] https://review.openstack.org/#/c/358321/

RegardsBharath T  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Yong Sheng Gong for Tacker core team

[bharath thiruveedula]

+1
From: jankih...@gmail.com
Date: Tue, 23 Aug 2016 22:37:09 +0530
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tacker] Proposing Yong Sheng Gong for Tacker core 
team

+1

On 23-Aug-2016 10:36 pm, "HADDLETON, Robert W (Bob)"  
wrote:

  

  
  
+1

  

  On 8/23/2016 10:55 AM, Sridhar Ramaswamy wrote:



  
  
Tackers,





I'd like to
  propose Yong Sheng Gong to join the Tacker core team. Yong is
  a seasoned OpenStacker and has been contributing to Tacker
  project since Nov 2015 (early Mitaka). He has been the major
  force in helping Tacker to shed its Neutronisms. He
  has low tolerance on unevenness in the code base and he fixes
  them as he goes. Yong also participated in the Enhanced
  Placement Awareness (EPA) blueprint in the Mitaka cycle. For
  Newton he took up himself cleaning up the DB schema and in
  numerous reviews to keep the project going. He has been a
  dependable member of the Tacker community [1].





Please chime
  in with your +1 / -1 votes.




thanks,

Sridhar




[1] http://stackalytics.com/report/contribution/tacker/90
  
  

  
  

  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




  


__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev   
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to Tacker core team

[bharath thiruveedula]

+1
To: openstack-dev@lists.openstack.org
From: bob.haddle...@nokia.com
Date: Fri, 17 Jun 2016 12:12:13 -0500
Subject: Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to Tacker 
core team


  

  
  
+1.  Kanagaraj will be a great addition
  to the team.

  

  Bob

  

  On 6/16/2016 1:45 PM, Karthik Natarajan wrote:



  
  
  
  
+1.
Thanks Kanagaraj for making such a great impact during the
Newton cycle.
 

  
From:
Sripriya Seetharam [mailto:ssee...@brocade.com]


Sent: Thursday, June 16, 2016 10:35 AM

To: OpenStack Development Mailing List (not for
usage questions)


Subject: Re: [openstack-dev] [tacker] Proposing
Kanagaraj Manickam to Tacker core team
  

 
+1

 
 
-Sripriya
 
 
From:
Sridhar Ramaswamy [mailto:sric...@gmail.com]


Sent: Wednesday, June 15, 2016 6:32 PM

To: OpenStack Development Mailing List (not for usage
questions) 

Subject: [openstack-dev] [tacker] Proposing Kanagaraj
Manickam to Tacker core team
 

  Tackers,



It gives me great pleasure to propose Kanagaraj Manickam to
join the Tacker core team. In a short time, Kanagaraj has
grown into a key member of the Tacker team. His enthusiasm
and dedication to get Tacker code base on par with other
leading OpenStack projects is very much appreciated. He is
already working on two important specs in Newton cycle and
many more fixes and RFEs [1]. Kanagaraj is also a core
member in the Heat project and this lends well as we heavily
use Heat for many Tacker features.



Please provide your +1/-1 votes.



- Sridhar



[1] 
http://stackalytics.com/?module=tacker-group_id=kanagaraj-manickam=marks

  
  

  
  

  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




  


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev   
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] Unable to launch nova instance with the new flavor

[bharath thiruveedula]

Hi,
With the master branch, I couldn't launch heat stack with the following 
template, giving the error "ERROR: No Flavor matching {'name': u'flavor_1'}. 
(HTTP 404)"
heat_template_version: 2015-04-30
description: Simple template to deploy a single compute instance
resources:   ins1: type: OS::Nova::Server properties:   flavor: 
{get_resource: flavor_1}   image: Fedora
   flavor_1: type: OS::Nova::Flavor properties: disk: 1 
vcpus: 1 ram: 1

But with "stable/liberty" branch, I can launch the heat stack. 
Anyone aware of this issue? Can anyone help me on this issue?
RegardsBharath T
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tacker]Automatic Resource Creation

[bharath thiruveedula]

Hi Tackers,

I have uploaded a new patchset for the automatic resource creation spec[1]. I 
haven't addressed some comments and as I am unable to attend to mitaka midcycle 
meetup, I am sharing below few thoughts on this spec.

Image Creation:

In the latest patchset, image creation at the time of onboarding, is the only 
reason for maintaining state for VNFD. As we discussed earlier, it may get 
difficult for the new users to understand "state for templates?". So it is 
better to  move image creation too on VNF creation. So if the template has uri, 
for the first VNF creation, we create the image and store image id for future 
VNF deployments. So using this option, we can provide parametrization of 
templates for images also and we can remove the statefulness for VNFD.
Flavor Creaton:
We can apply the same above rule in this case also. we store flavor IDs while 
deploying the first VNF and later reuse the same IDs.
Network Creation:
We can apply same rule here.
Let me know your comments
[1]https://review.openstack.org/#/c/250291/
RegardsBharath T
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker]Automatic Resource Creation

[bharath thiruveedula]

Hi Sridhar,
If we use Heat to create flavor and network, we may end up having multiple 
flavors and networks(which are of same)for a VNFD.
RegardsBharath T
Date: Tue, 26 Jan 2016 11:22:34 -0800
From: sric...@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tacker]Automatic Resource Creation

Hi Bharath,
As further discussed in today's IRC meeting [1], the image creation proposal 
you laid out seems a reasonable near term approach. 
It also doesn't preclude future enhancements to do image-download during VNFD 
on-boarding (image pre-positiong in a multi-site scenario). In that case VNFD 
in the Catalog will already have references to glance image(s) in the target 
VIM and the VNF creation can directly proceed to the instantiation phase.
On the Flavor and Network creation I would strongly suggest to stick with Heat 
resources and leverage TOSCA -> HOT conversion to achieve them and not go 
directly to Nova and Neutron for this purpose. 
thanks,Sridhar
[1] 
http://eavesdrop.openstack.org/meetings/tacker/2016/tacker.2016-01-26-17.00.log.html
On Tue, Jan 26, 2016 at 6:19 AM, bharath thiruveedula <bharath_...@hotmail.com> 
wrote:






Hi Tackers,

I have uploaded a new patchset for the automatic resource creation spec[1]. I 
haven't addressed some comments and as I am unable to attend to mitaka midcycle 
meetup, I am sharing below few thoughts on this spec.

Image Creation:

In the latest patchset, image creation at the time of onboarding, is the only 
reason for maintaining state for VNFD. As we discussed earlier, it may get 
difficult for the new users to understand "state for templates?". So it is 
better to  move image creation too on VNF creation. So if the template has uri, 
for the first VNF creation, we create the image and store image id for future 
VNF deployments. So using this option, we can provide parametrization of 
templates for images also and we can remove the statefulness for VNFD.
Flavor Creaton:
We can apply the same above rule in this case also. we store flavor IDs while 
deploying the first VNF and later reuse the same IDs.
Network Creation:
We can apply same rule here.
Let me know your comments
[1]https://review.openstack.org/#/c/250291/
RegardsBharath T
  

__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev   
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Mesos Conductor

[bharath thiruveedula]

Hi,
As per the discussion in [1], I have pushed patchset [1]. Can you please review 
 the patch. I want to take comments on this patch before I push test cases and 
container-list operation because there was a discussion on this topic whether 
to have this or not. (from my previous experience :) ). 
RegardsBharath T
[1]http://lists.openstack.org/pipermail/openstack-dev/2015-December/081818.html[2]https://review.openstack.org/#/c/258860/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [magnum] Mesos Conductor patch for review

[bharath thiruveedula]

Hi,As per the discussion in [1], I have pushed patchset [1]. Can you please 
review  the patch. I want to take comments on this patch before I push test 
cases and container-list operation because there was a discussion on this topic 
whether to have this or not. (from my previous experience :) ). RegardsBharath 
T[1]http://lists.openstack.org/pipermail/openstack-dev/2015-December/081818.html[2]https://review.openstack.org/#/c/258860/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Mesos Conductor using container-create operations

[bharath thiruveedula]

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

From: bharath_...@hotmail.com
To: openstack-dev@lists.openstack.org
Date: Wed, 9 Dec 2015 10:10:17 +0530
Subject: [openstack-dev] Mesos Conductor using container-create operations




Hi,
As we have discussed in last meeting, we cannot continue with changes in 
container-create[1] as long as we have suitable use case. But I honestly feel 
to have some kind of support for mesos + marathon apps, because magnum supports 
COE related functionalities for docker swarm (container-create) and k8s 
(pod-create, rc-create..) but not for mesos bays.
As hongbin suggested, we use the existing functionality of container-create and 
support in mesos-conductor. Currently we have container-create only for docker 
swarm bay. Let's have support for the same command for mesos bay with out any 
changes in client side.
Let me know your suggestions.
RegardsBharath T  

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev   
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Mesos Conductor using container-create operations

[bharath thiruveedula]

Hi,
As we have discussed in last meeting, we cannot continue with changes in 
container-create[1] as long as we have suitable use case. But I honestly feel 
to have some kind of support for mesos + marathon apps, because magnum supports 
COE related functionalities for docker swarm (container-create) and k8s 
(pod-create, rc-create..) but not for mesos bays.
As hongbin suggested, we use the existing functionality of container-create and 
support in mesos-conductor. Currently we have container-create only for docker 
swarm bay. Let's have support for the same command for mesos bay with out any 
changes in client side.
Let me know your suggestions.
RegardsBharath T  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Mesos Conductor

[Bharath Thiruveedula]

Hi Jay,

Sorry I just saw your mail. I have pushed the patches for json-file support
for client[1] and backend[2].  If the team accepts the support the json
file support for container-create, I can link the client patch to your
blueprint and you can add patches for other features you mentioned, if you
don't mind. And we can discuss about the backend support patch in the
meeting.

[1]https://review.openstack.org/#/c/252775/
[2]https://review.openstack.org/#/c/252789/
Regards
Bharath T

On Thu, Dec 3, 2015 at 9:38 AM, Jay Lau <jay.lau@gmail.com> wrote:

> Hi Bharath,
>
> Actually I have already filed a bp here:
> https://blueprints.launchpad.net/magnum/+spec/unify-coe-api ,sorry for
> the late notify.
>
> We may need some discussion for this in next Week's meeting. I will attend
> next week's meeting and we can have discussion with team then, hope it is
> OK. ;-)
>
> Thanks!
>
> On Wed, Dec 2, 2015 at 8:48 AM, bharath thiruveedula <
> bharath_...@hotmail.com> wrote:
>
>> Hi,
>>
>> Sorry I was off for some days because of health issues.
>>
>> So I think the work items for this BP[1] are:
>>
>> 1)Add support to accept json file in container-create command
>> 2)Handle JSON input in docker_conductor
>> 3)Implement mesos conductor for container create,delete and list.
>>
>> Correct me if I am wrong. And let me know the process for implementing BP
>> in magnum. I think we need approval for this BP and then implementation?
>>
>>  [1]https://blueprints.launchpad.net/magnum/+spec/mesos-conductor
>>
>> Regards
>> Bharath T(tbh)
>>
>>
>> --
>> Date: Fri, 20 Nov 2015 07:44:49 +0800
>> From: jay.lau@gmail.com
>> To: openstack-dev@lists.openstack.org
>>
>> Subject: Re: [openstack-dev] [magnum] Mesos Conductor
>>
>> It's great that we come to some agreement on unifying the client call ;-)
>>
>> As i proposed in previous thread, I think that "magnum app-create" may be
>> better than "magnum create", I want to use "magnum app-create" to
>> distinguish with "magnum container-create". The "app-create" may also not a
>> good name as the k8s also have concept of service which is actually not an
>> app. comments?
>>
>> I think we can file a bp for this and it will be a great feature in M
>> release!
>>
>> On Fri, Nov 20, 2015 at 4:59 AM, Egor Guz <e...@walmartlabs.com> wrote:
>>
>> +1, I found that 'kubectl create -f FILENAME’ (
>> https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_create.md)
>> works very well for different type of objects and I think we should try to
>> use it.
>>
>> but I think we should support two use-cases
>>  - 'magnum container-create’, with simple list of options which work for
>> Swarm/Mesos/Kub. it will be good option for users who just wants to try
>> containers.
>>  - 'magnum create ’, with file which has Swarm/Mesos/Kub specific payload.
>>
>> —
>> Egor
>>
>> From: Adrian Otto <adrian.o...@rackspace.com> adrian.o...@rackspace.com>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>>
>> Date: Thursday, November 19, 2015 at 10:36
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org> openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [magnum] Mesos Conductor
>>
>> I’m open to allowing magnum to pass a blob of data (such as a lump of
>> JSON or YAML) to the Bay's native API. That approach strikes a balance
>> that’s appropriate.
>>
>> Adrian
>>
>> On Nov 19, 2015, at 10:01 AM, bharath thiruveedula <
>> bharath_...@hotmail.com<mailto:bharath_...@hotmail.com>> wrote:
>>
>> Hi,
>>
>> At the present scenario, we can have mesos conductor with existing
>> attributes[1]. Or we can add  extra options like 'portMappings',
>> 'instances', 'uris'[2]. And the other options is to take json file as input
>> to 'magnum container-create' and dispatch it to corresponding conductor.
>> And the conductor will handle the json input. Let me know your opinions.
>>
>>
>> Regards
>> Bharath T
>>
>>
>>
>>
>> [1]https://goo.gl/f46b4H
>> [2]https://mesosphere.github.io/marathon/docs/application-basics.html
>> 
>> To: openstack-dev@lists.openstack.org&g

Re: [openstack-dev] [magnum] Mesos Conductor

[bharath thiruveedula]

Hi,
Sorry I was off for some days because of health issues.
So I think the work items for this BP[1] are:
1)Add support to accept json file in container-create command2)Handle JSON 
input in docker_conductor3)Implement mesos conductor for container 
create,delete and list.
Correct me if I am wrong. And let me know the process for implementing BP in 
magnum. I think we need approval for this BP and then implementation?
 [1]https://blueprints.launchpad.net/magnum/+spec/mesos-conductor
RegardsBharath T(tbh)

Date: Fri, 20 Nov 2015 07:44:49 +0800
From: jay.lau@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] Mesos Conductor

It's great that we come to some agreement on unifying the client call ;-)

As i proposed in previous thread, I think that "magnum app-create" may be 
better than "magnum create", I want to use "magnum app-create" to distinguish 
with "magnum container-create". The "app-create" may also not a good name as 
the k8s also have concept of service which is actually not an app. comments?

I think we can file a bp for this and it will be a great feature in M release!

On Fri, Nov 20, 2015 at 4:59 AM, Egor Guz <e...@walmartlabs.com> wrote:
+1, I found that 'kubectl create -f FILENAME’ 
(https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_create.md)
 works very well for different type of objects and I think we should try to use 
it.



but I think we should support two use-cases

 - 'magnum container-create’, with simple list of options which work for 
Swarm/Mesos/Kub. it will be good option for users who just wants to try 
containers.

 - 'magnum create ’, with file which has Swarm/Mesos/Kub specific payload.



―

Egor



From: Adrian Otto <adrian.o...@rackspace.com<mailto:adrian.o...@rackspace.com>>

Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

Date: Thursday, November 19, 2015 at 10:36

To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>

Subject: Re: [openstack-dev] [magnum] Mesos Conductor



I’m open to allowing magnum to pass a blob of data (such as a lump of JSON or 
YAML) to the Bay's native API. That approach strikes a balance that’s 
appropriate.



Adrian



On Nov 19, 2015, at 10:01 AM, bharath thiruveedula 
<bharath_...@hotmail.com<mailto:bharath_...@hotmail.com>> wrote:



Hi,



At the present scenario, we can have mesos conductor with existing 
attributes[1]. Or we can add  extra options like 'portMappings', 'instances', 
'uris'[2]. And the other options is to take json file as input to 'magnum 
container-create' and dispatch it to corresponding conductor. And the conductor 
will handle the json input. Let me know your opinions.





Regards

Bharath T









[1]https://goo.gl/f46b4H

[2]https://mesosphere.github.io/marathon/docs/application-basics.html



To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>

From: wk...@cn.ibm.com<mailto:wk...@cn.ibm.com>

Date: Thu, 19 Nov 2015 10:47:33 +0800

Subject: Re: [openstack-dev] [magnum] Mesos Conductor



@bharath,



1) actually, if you mean use container-create(delete) to do on mesos bay for 
apps. I am not sure how different the interface between docker interface and 
mesos interface. One point that when you introduce that feature, please not 
make docker container interface more complicated than now. I worried that 
because it would confuse end-users a lot than the unified benefits. (maybe as 
optional parameter to pass one json file to create containers in mesos)



2) For the unified interface, I think it need more thoughts, we need not bring 
more trouble to end-users to learn new concepts or interfaces, except we could 
have more clear interface, but different COES vary a lot. It is very challenge.







Thanks



Best Wishes,



Kai Qiang Wu (吴开强 Kennan）

IBM China System and Technology Lab, Beijing



E-mail: wk...@cn.ibm.com<mailto:wk...@cn.ibm.com>

Tel: 86-10-82451647

Address: Building 28(Ring Building), ZhongGuanCun Software Park,

No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

--------

Follow your heart. You are miracle!



[Inactive hide details for bharath thiruveedula ---19/11/2015 10:31:58 
am---@hongin, @adrian I agree with you. So can we go ahea]bharath thiruveedula 
---19/11/2015 10:31:58 am---@hongin, @adrian I agree with you. So can we go 
ahead with magnum container-create(delete) ... for



From:  bharath thiruveedula 
<bharath_...@hotmail.com<mailto

Re: [openstack-dev] [magnum] Mesos Conductor

[bharath thiruveedula]

Hi,
At the present scenario, we can have mesos conductor with existing 
attributes[1]. Or we can add  extra options like 'portMappings', 'instances', 
'uris'[2]. And the other options is to take json file as input to 'magnum 
container-create' and dispatch it to corresponding conductor. And the conductor 
will handle the json input. Let me know your opinions.

RegardsBharath T



[1]https://goo.gl/f46b4H[2]https://mesosphere.github.io/marathon/docs/application-basics.html
To: openstack-dev@lists.openstack.org
From: wk...@cn.ibm.com
Date: Thu, 19 Nov 2015 10:47:33 +0800
Subject: Re: [openstack-dev] [magnum] Mesos Conductor

@bharath, 

1) actually, if you mean use container-create(delete) to do on mesos bay for 
apps.  I am not sure how different the interface between docker interface and 
mesos interface. One point that when you introduce that feature, please not 
make docker container interface more complicated than now. I worried that 
because it would confuse end-users a lot than the unified benefits. (maybe as 
optional parameter to pass one json file to create containers in mesos)

2) For the unified interface, I think it need more thoughts, we need not bring 
more trouble to end-users to learn new concepts or interfaces, except we could 
have more clear interface, but different COES vary a lot. It is very challenge. 



Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,  
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

Follow your heart. You are miracle! 

bharath thiruveedula ---19/11/2015 10:31:58 am---@hongin, @adrian I agree with 
you. So can we go ahead with magnum container-create(delete) ...  for

From:bharath thiruveedula <bharath_...@hotmail.com>
To:OpenStack Development Mailing List not for usage questions 
<openstack-dev@lists.openstack.org>
Date:19/11/2015 10:31 am
Subject:Re: [openstack-dev] [magnum] Mesos Conductor




@hongin, @adrian I agree with you. So can we go ahead with magnum 
container-create(delete) ...  for mesos bay (which actually create 
mesos(marathon) app internally)?

@jay, yes we multiple frameworks which are using mesos lib. But the mesos bay 
we are creating uses marathon. And we had discussion in irc on this topic, and 
I was asked to implement initial version for marathon. And agree with you to 
have unified client interface for creating pod,app.

Regards
Bharath T  

Date: Thu, 19 Nov 2015 10:01:35 +0800
From: jay.lau@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] Mesos Conductor

+1.

One problem I want to mention is that for mesos integration, we cannot limited 
to Marathon + Mesos as there are many frameworks can run on top of Mesos, such 
as Chronos, Kubernetes etc, we may need to consider more for Mesos integration 
as there is a huge eco-system build on top of Mesos.

On Thu, Nov 19, 2015 at 8:26 AM, Adrian Otto <adrian.o...@rackspace.com> 
wrote:Bharath,

I agree with Hongbin on this. Let’s not expand magnum to deal with apps or 
appgroups in the near term. If there is a strong desire to add these things, we 
could allow it by having a plugin/extensions interface for the Magnum API to 
allow additional COE specific features. Honestly, it’s just going to be a 
nuisance to keep up with the various upstreams until they become completely 
stable from an API perspective, and no additional changes are likely. All of 
our COE’s still have plenty of maturation ahead of them, so this is the wrong 
time to wrap them.

If someone really wants apps and appgroups, (s)he could add that to an 
experimental branch of the magnum client, and have it interact with the 
marathon API directly rather than trying to represent those resources in 
Magnum. If that tool became popular, then we could revisit this topic for 
further consideration.

Adrian

> On Nov 18, 2015, at 3:21 PM, Hongbin Lu <hongbin...@huawei.com> wrote:
>
> Hi Bharath,
>
> I agree the “container” part. We can implement “magnum container-create ..” 
> for mesos bay in the way you mentioned. Personally, I don’t like to introduce 
> “apps” and “appgroups” resources to Magnum, because they are already provided 
> by native tool [1]. I couldn’t see the benefits to implement a wrapper API to 
> offer what native tool already offers. However, if you can point out a valid 
> use case to wrap the API, I will give it more thoughts.
>
> Best regards,
> Hongbin
>
> [1] https://docs.mesosphere.com/using/cli/marathonsyntax/
>
> From: bharath thiruveedula [mailto:bharath_...@hotmail.com]
> Sent: November-18-15 1:20 PM
> To: open

[openstack-dev] [tacker] Automatic flavor creation

[bharath thiruveedula]

Hi tackers,
I am working on automatic flavor creation RFE[1]. I have written my thoughts on 
implementing on it. I would like to see your comments on it. Due to time 
differences, I was not able to directly ping core members in IRC.
[1]https://bugs.launchpad.net/tacker/+bug/1516193
RegardsBharath T  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [magnum] Mesos Conductor

[bharath thiruveedula]

Hi all,I am working on the blueprint [1]. As per my understanding, we have two 
resources/objects in mesos+marathon:1)Apps: combination of instances/containers 
running on multiple hosts representing a service.[2]2)Application Groups: Group 
of apps, for example we can have database application group which consists 
mongoDB app and MySQL App.[3]So I think we need to have two resources 'apps' 
and 'appgroups' in mesos conductor like we have pod and rc for k8s. And 
regarding 'magnum container' command, we can create, delete and retrieve 
container details as part of mesos app itself(container =  app with 1 
instance). Though I think in mesos case 'magnum app-create ..."  and 'magnum 
container-create ...' will use the same REST API for both cases. Let me know 
your opinion/comments on this and correct me if I am 
wrong[1]https://blueprints.launchpad.net/magnum/+spec/mesos-conductor.[2]https://mesosphere.github.io/marathon/docs/application-basics.html[3]https://mesosphere.github.io/marathon/docs/application-groups.htmlRegardsBharath
 T __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Mesos Conductor

[bharath thiruveedula]

@hongin, @adrian I agree with you. So can we go ahead with magnum 
container-create(delete) ...  for mesos bay (which actually create 
mesos(marathon) app internally)?
@jay, yes we multiple frameworks which are using mesos lib. But the mesos bay 
we are creating uses marathon. And we had discussion in irc on this topic, and 
I was asked to implement initial version for marathon. And agree with you to 
have unified client interface for creating pod,app.
RegardsBharath T  

Date: Thu, 19 Nov 2015 10:01:35 +0800
From: jay.lau@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] Mesos Conductor

+1.

One problem I want to mention is that for mesos integration, we cannot limited 
to Marathon + Mesos as there are many frameworks can run on top of Mesos, such 
as Chronos, Kubernetes etc, we may need to consider more for Mesos integration 
as there is a huge eco-system build on top of Mesos.

On Thu, Nov 19, 2015 at 8:26 AM, Adrian Otto <adrian.o...@rackspace.com> wrote:
Bharath,



I agree with Hongbin on this. Let’s not expand magnum to deal with apps or 
appgroups in the near term. If there is a strong desire to add these things, we 
could allow it by having a plugin/extensions interface for the Magnum API to 
allow additional COE specific features. Honestly, it’s just going to be a 
nuisance to keep up with the various upstreams until they become completely 
stable from an API perspective, and no additional changes are likely. All of 
our COE’s still have plenty of maturation ahead of them, so this is the wrong 
time to wrap them.



If someone really wants apps and appgroups, (s)he could add that to an 
experimental branch of the magnum client, and have it interact with the 
marathon API directly rather than trying to represent those resources in 
Magnum. If that tool became popular, then we could revisit this topic for 
further consideration.



Adrian



> On Nov 18, 2015, at 3:21 PM, Hongbin Lu <hongbin...@huawei.com> wrote:

>

> Hi Bharath,

>

> I agree the “container” part. We can implement “magnum container-create ..” 
> for mesos bay in the way you mentioned. Personally, I don’t like to introduce 
> “apps” and “appgroups” resources to Magnum, because they are already provided 
> by native tool [1]. I couldn’t see the benefits to implement a wrapper API to 
> offer what native tool already offers. However, if you can point out a valid 
> use case to wrap the API, I will give it more thoughts.

>

> Best regards,

> Hongbin

>

> [1] https://docs.mesosphere.com/using/cli/marathonsyntax/

>

> From: bharath thiruveedula [mailto:bharath_...@hotmail.com]

> Sent: November-18-15 1:20 PM

> To: openstack-dev@lists.openstack.org

> Subject: [openstack-dev] [magnum] Mesos Conductor

>

> Hi all,

>

> I am working on the blueprint [1]. As per my understanding, we have two 
> resources/objects in mesos+marathon:

>

> 1)Apps: combination of instances/containers running on multiple hosts 
> representing a service.[2]

> 2)Application Groups: Group of apps, for example we can have database 
> application group which consists mongoDB app and MySQL App.[3]

>

> So I think we need to have two resources 'apps' and 'appgroups' in mesos 
> conductor like we have pod and rc for k8s. And regarding 'magnum container' 
> command, we can create, delete and retrieve container details as part of 
> mesos app itself(container =  app with 1 instance). Though I think in mesos 
> case 'magnum app-create ..."  and 'magnum container-create ...' will use the 
> same REST API for both cases.

>

> Let me know your opinion/comments on this and correct me if I am wrong

>

> [1]https://blueprints.launchpad.net/magnum/+spec/mesos-conductor.

> [2]https://mesosphere.github.io/marathon/docs/application-basics.html

> [3]https://mesosphere.github.io/marathon/docs/application-groups.html

>

>

> Regards

> Bharath T

> __

> OpenStack Development Mailing List (not for usage questions)

> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Thanks,

Jay Lau (Guangya Liu)



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev   
   

Re: [openstack-dev] [tacker] Proposing Sripriya Seetharam to Tacker core

[Bharath Thiruveedula]

+1

On Tue, Nov 10, 2015 at 10:42 PM, Stephen Wong 
wrote:

> +1
>
> On Mon, Nov 9, 2015 at 6:22 PM, Sridhar Ramaswamy 
> wrote:
>
>> I'd like to propose Sripriya Seetharam to join the Tacker core team.
>> Sripriya
>> ramped up quickly in early Liberty cycle and had become an expert in the
>> Tacker
>> code base. Her major contributions include landing MANO API blueprint,
>> introducing unit test framework along with the initial unit-tests and
>> tirelessly
>> squashing hard to resolve bugs (including chasing the recent nova-neutron
>> goose
>> hunt). Her reviews are solid fine tooth comb and constructive [1].
>>
>> I'm glad to welcome Sripriya to the core team. Current cores members,
>> please vote
>> with your +1 / -1.
>>
>> [1]
>> http://stackalytics.com/?release=libertyuser_id=sseethaproject_type=openstack-others
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] Coe components status

[Bharath Thiruveedula]

+ 1 to vikas.

As we have monitor framework only to docker swarm COE at present and we are
pushing other COE drivers in future. So it is better to have component
status for one COE at first and will push other COEs support later. Correct
me if I am wrong.

Regards
Bharath T

On Wed, Oct 21, 2015 at 9:26 AM, Vikas Choudhary  wrote:

> @ Eli ,
>
> I will look into how to support this feature for other COEs also(mesos and
> swarm). But anyways Magnum's goal is to provide users *atleast* what other
> coes are providing (if not something extra). All coes dont have common
> features, so we cant be very strict on providing common interface apis for
> all coes. For example "magnum container" commands work only with swarm not
> k8s or mesos.
> It will not be justified if k8s is providing a way to monitor at more
> granular level but magnum will not allow user to use it just beacuse other
> coes does not provide this feature.
>
> Agree that it will be nice if could support this feature for all. I will
> prefer to start with k8s first and if similar feature is supported by mesos
> and swarm also, incrementally will implement that also.
>
> Regards
> Vikas Choudhary
>
> On Wed, Oct 21, 2015 at 6:50 AM, Qiao,Liyong 
> wrote:
>
>> hi Vikas,
>> thanks for propose this changes, I wonder if you can show some examples
>> for other coes we currently supported:
>> swarm, mesos ?
>>
>> if we propose a public api like you proposed, we'd better to support all
>> coes instead of coe specific.
>>
>> thanks
>> Eli.
>>
>>
>> On 2015年10月20日 18:14, Vikas Choudhary wrote:
>>
>> Hi Team,
>>
>> I would appreciate any opinion/concern regarding "coe-component-status"
>> feature implementation [1].
>>
>> For example in k8s, using API api/v1/namespaces/{namespace}
>> /componentstatuses, status of each k8s component can be queried. My
>> approach would be to provide a command in magnum like "magnum
>> coe-component-status" leveraging coe provided rest api and result will be
>> shown to user.
>>
>> [1] https://blueprints.launchpad.net/magnum/+spec/coe-component-status
>>
>>
>>
>> -Vikas Choudhary
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> --
>> BR, Eli(Li Yong)Qiao
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tacker] Proposing Bob Haddleton to core team

[Bharath Thiruveedula]

+1

-Bharath T

On Thu, Oct 15, 2015 at 10:36 PM, Stephen Wong 
wrote:

> +1
>
> - Stephen
>
> On Thu, Oct 15, 2015 at 8:47 AM, Sridhar Ramaswamy 
> wrote:
>
>> I would like to nominate Bob Haddleton to the Tacker core team.
>>
>> In the current Liberty cycle Bob made significant, across the board
>> contributions to Tacker [1]. Starting with many usability enhancements and
>> squashing bugs Bob has shown commitment and consistently produced high
>> quality code. To cap he recently landed Tacker's health monitoring
>> framework to enable loadable VNF monitoring. His knowledge in NFV area is a
>> huge plus for Tacker as we embark onto even greater challenges in the
>> Mitaka cycle.
>>
>> Along the lines, we are actively looking to expand Tacker's core reviewer
>> team. If you are interested in the NFV Orchestration / VNF Manager space
>> please stop by and explore Tacker project [2].
>>
>> Tacker team,
>>
>> Please provide your -1 / +1 votes.
>>
>> - Sridhar
>>
>> [1]  
>> http://stackalytics.com/report/users/bob-haddleton
>> [2]  
>> https://wiki.openstack.org/wiki/Tacker
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] New PyCharm License

[Bharath Thiruveedula]

Hi  Andrew,

My Launchpad ID is "bharath-ves"

Regards
Bharath T

On Mon, Sep 21, 2015 at 8:24 PM, Andrew Melton 
wrote:

> Hi devs,
>
>
> I've got the new license for the next year. As always, please reply to
> this email with your launchpad-id if you would like a license.
>
>
> Also, if there are other JetBrains products you use to contribute to
> OpenStack, please let me know and I will request licenses.
>
> ​
>
> --Andrew
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Debug tool for neutron

[bharath thiruveedula]

Hi,
We have some troubleshooting guides for openstack neutron. But many people who 
are new to neutron find it difficult to follow the guides, as they are not 
aware of what is happening behind the scenes. So is there any tool which tracks 
the packet flow from the VM to debug issues like why the VM  is not getting the 
IP Address or why internet is not reachable from the VM? If any, can you please 
suggest some of them?

RegardsBharath__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] unable to reproduce bug 1317363‏

[bharath thiruveedula]

Yeah sure

From: blak...@gmail.com
Date: Mon, 2 Feb 2015 11:09:08 -0800
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev][Neutron] unable to reproduce bug 1317363‏

The mailing list isn't a great place to discuss reproducing a bug. Post this 
comment on the bug report instead of the mailing list. That way the person who 
reported it and the ones who triaged it can see this information and respond. 
They might not be watching the dev mailing list as closely.


On Mon, Feb 2, 2015 at 10:17 AM, bharath thiruveedula bharath_...@hotmail.com 
wrote:



Hi,
I am Bharath Thiruveedula. I am new to openstack neutron and networking. I am 
trying to solve the bug 1317363. But I am unable to reproduce that bug. The 
steps I have done to reproduce:
1)I have created with network with external = True2)Created a subnet for the 
above network with CIDR=172.24.4.0/24 with gateway-ip =172.24.4.53)Created the 
router4)Set the gateway interface to the router5)Tried to change subnet 
gateway-ip but got this errorGateway ip 172.24.4.7 conflicts with allocation 
pool 172.24.4.6-172.24.4.254I used this command for thatneutron subnet-update 
ff9fe828-9ca2-42c4-9997-3743d8fc0b0c --gateway-ip 172.24.4.7 
Can you please help me with this issue?

-- Bharath Thiruveedula   

__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev   
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] unable to reproduce bug 1317363‏

[bharath thiruveedula]

Hi,
I am Bharath Thiruveedula. I am new to openstack neutron and networking. I am 
trying to solve the bug 1317363. But I am unable to reproduce that bug. The 
steps I have done to reproduce:
1)I have created with network with external = True2)Created a subnet for the 
above network with CIDR=172.24.4.0/24 with gateway-ip =172.24.4.53)Created the 
router4)Set the gateway interface to the router5)Tried to change subnet 
gateway-ip but got this errorGateway ip 172.24.4.7 conflicts with allocation 
pool 172.24.4.6-172.24.4.254I used this command for thatneutron subnet-update 
ff9fe828-9ca2-42c4-9997-3743d8fc0b0c --gateway-ip 172.24.4.7 
Can you please help me with this issue?

-- Bharath Thiruveedula   __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev