Re: NetworkOrchestrator selects 2 NetworkGurus at one time....

[Pradeep Cloudstack]

Hi,
do we have solution for this in 4.5 ?

An ideal solution would be to have a single Network created, but let each of 
the NetworkGuru do the implementation

-Pradeep




 From: Chiradeep Vittal 
To: Pradeep Cloudstack ; 
"dev@cloudstack.apache.org"  
Cc: Sheng Yang ; Jayapal Reddy Uradi 
; Alena Prokharchyk 
 
Sent: Friday, June 27, 2014 12:11 AM
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time
 

For 4.3/4.4, I’m guessing this is the same solution.

For 4.5, here’s a couple of options we could implement:

  1.  New isolation provider (“BrocadeVLAN” or “JuniperEXVLAN”)
  2.  When creating the network offering, the administrator gets to select the 
guru
  3.  New VLAN provider mechanism.

From: Pradeep Cloudstack 
mailto:pradeepcloudst...@yahoo.com>>
Reply-To: Pradeep Cloudstack 
mailto:pradeepcloudst...@yahoo.com>>
Date: Wednesday, June 25, 2014 at 3:06 AM
To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
mailto:dev@cloudstack.apache.org>>, Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>
Cc: Sheng Yang mailto:sheng.y...@citrix.com>>, Jayapal 
Reddy Uradi 
mailto:jayapalreddy.ur...@citrix.com>>, Alena 
Prokharchyk mailto:alena.prokharc...@citrix.com>>
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

We have a use-case where we will patch an existing 4.3 installation with our 
plugin.
We are facing the same issue .
In 4.2, we used to disable the entry for ExternalNetworkGuru in
componentContext.xml as part of installing the patch.

How do we do this in 4.3 (on an existing installation) ?

-Pradeep


From: Ritu Sabharwal mailto:rsabh...@brocade.com>>
To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
mailto:dev@cloudstack.apache.org>>; Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>
Cc: Sheng Yang mailto:sheng.y...@citrix.com>>; Jayapal 
Reddy Uradi 
mailto:jayapalreddy.ur...@citrix.com>>; Alena 
Prokharchyk mailto:alena.prokharc...@citrix.com>>
Sent: Thursday, June 12, 2014 12:13 AM
Subject: RE: NetworkOrchestrator selects 2 NetworkGurus at one time

Thanks Chiradeep and Murali for the reply!

I am thinking of explicitly telling ExternalNetworkGuru to skip design when 
Brocade plugin is designing the network. I don't want to disable 
ExternalNetworkGuru from default build when Brocade plugin is not present so 
won't exclude it from the spring class loader.

Thanks & Regards,
Ritu S.



-Original Message-
From: Murali Reddy 
[mailto:murali.re...@citrix.com<mailto:murali.re...@citrix.com>]
Sent: Tuesday, June 10, 2014 10:54 PM
To: Chiradeep Vittal; 
dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
Cc: Sheng Yang; Jayapal Reddy Uradi; Alena Prokharchyk
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

This is know design issue. Unlike service orchestration (which has prescriptive 
way to tell which network elements to be called for with network offerings ) 
there is no such logic for network design. Orchestrator just loops through all 
the network guru's asking to design the network which can results in one or 
more networks. Hugo did a cleanup [1] but I believe it was not merged as there 
was no consensus. There is 1-1 mapping between isolation type and Guru but In 
this case both Brocade Guru and ExternalNetworkGuru will attempt to design the 
VLAN isolated networks.

One in-elegent solution is to hard code ExternalGuestNetworu guru to skip 
network deign when Brocade plug-in is supposed to do design the network. Other 
option could be exclude ExternalNetworkGuru bean from spring class loader.

[1] https://www.mail-archive.com/dev@cloudstack.apache.org/msg17344.html

From: Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com><mailto:chiradeep.vit...@citrix.com<mailto:chiradeep.vit...@citrix.com>>>
Date: Wednesday, 11 June 2014 6:24 AM
To: 
"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>"
 
mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>>
Cc: Sheng Yang 
mailto:sheng.y...@citrix.com><mailto:sheng.y...@citrix.com<mailto:sheng.y...@citrix.com>>>,
 Murali Reddy 
mailto:murali.re...@citrix.com><mailto:murali.re...@citrix.com<mailto:murali.re...@citrix.com>>>,
 Jayapal Reddy Uradi 
mailto:jayapalreddy.ur...@citrix.com><mailto:jayapalreddy.ur...@citrix.com<mailto:jayapalreddy.ur...@citrix.com>>>,
 Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com><mailto:alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>>>
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one

Re: Inter-network Communication

[Pradeep Cloudstack]

Thanks Gaurav.
Is there a UI for this ?
In the 4.5 UI, when I click on Network, I see only the "Egress rules" tab


-Pradeep




 From: Gaurav Aradhye 
To: "dev@cloudstack.apache.org" ; Pradeep Cloudstack 
 
Sent: Thursday, September 18, 2014 6:33 PM
Subject: Re: Inter-network Communication
 


Pradeep,

You can configure ingress rules too. For ex. API authorizeSecurityGroupIngress
And if you are not using security groups, then you can configure Port 
Forawrding/LB rules for specific ports in Isolated networks that will serve as 
your ingress rules.


Regards,
Gaurav




On Thu, Sep 18, 2014 at 3:20 PM, Pradeep Cloudstack 
 wrote:

Thanks Gaurav.
>
>I see that we can configure only Egress Rules for a Network. Why not Ingress 
>Rules ?
>
>-Pradeep
>
>
>
>
> From: Gaurav Aradhye 
>To: "dev@cloudstack.apache.org" ; Pradeep 
>Cloudstack 
>Sent: Thursday, September 18, 2014 11:57 AM
>Subject: Re: Inter-network Communication
>
>
>
>Pradeep,
>
>You have not mentioned any intern-network communication here. If all
>departments are independent, you can have isolated network for each account
>and then configure FireWall Rules for the network individually according to
>you needs.
>
>Another option is you can use security groups in advanced zone. Have
>security group for each department, and then you can configure traffic for
>each security group. You can also specify the communication between two
>security groups with the help of ingress and egress rules.
>
>Regards,
>Gaurav
>
>
>
>
>On Thu, Sep 18, 2014 at 9:22 AM, Pradeep Cloudstack <
>pradeepcloudst...@yahoo.com.invalid> wrote:
>
>> I am working on a Proof-Of-Concept for a private cloud setup.
>> Here is the organizational requirement:
>> - Organization has Finance, Engineering and Marketing departments
>> - Each Dept has a Cloudstack account
>> - Each Dept has a separate network to which VMs are attached
>> - Access to the Finance Dept Network should go through Firewall security
>> - Access to the Marketing Dept Network shouldnot go through Firewall
>> security
>>
>> - VMs in Engineering network can only communicate with each other but not
>> with VMs in other networks
>>
>>
>> The VPC feature doesnot help in this case as there are different accounts
>> for each tenant
>>
>> Can you pls guide me on how I can achieve this ?
>>
>>
>> -Pradeep
>>
>>
>> 
>>  From: Jayapal Reddy Uradi 
>> To: "" ; Pradeep
>> Cloudstack 
>> Sent: Wednesday, September 17, 2014 5:03 PM
>> Subject: Re: Inter-network Communication
>>
>>
>> Hi Pradeep,
>>
>> In cloudstack create network and launch vm in that to create router.
>> To communicate between the networks depends on the network type in
>> cloudstack.
>>
>> If you want multiple networks with single router use VPC networks/tiers
>> and configure ACL between them.
>>
>> Isolated networks will one router per each network. If vm want to
>> communicate to other network
>> it can be done by  adding nic in that network or Create nat,firewall rules
>> to reach vms in other network.
>>
>> Thanks,
>> Jayapal
>>
>>
>> On 17-Sep-2014, at 4:40 PM, Pradeep Cloudstack
>> 
>> wrote:
>>
>> > In OpenStack, there is a workflow wherein user can create multiple
>> networks, then create a router
>> > and attach to it some of the previously created networks to enable
>> inter-network communication.
>> >
>> > What is the equivalent workflow in Cloudstack ?
>> >
>> > -Pradeep
>>

Re: Inter-network Communication

[Pradeep Cloudstack]

Thanks Gaurav.

I see that we can configure only Egress Rules for a Network. Why not Ingress 
Rules ?

-Pradeep




 From: Gaurav Aradhye 
To: "dev@cloudstack.apache.org" ; Pradeep Cloudstack 
 
Sent: Thursday, September 18, 2014 11:57 AM
Subject: Re: Inter-network Communication
 

Pradeep,

You have not mentioned any intern-network communication here. If all
departments are independent, you can have isolated network for each account
and then configure FireWall Rules for the network individually according to
you needs.

Another option is you can use security groups in advanced zone. Have
security group for each department, and then you can configure traffic for
each security group. You can also specify the communication between two
security groups with the help of ingress and egress rules.

Regards,
Gaurav




On Thu, Sep 18, 2014 at 9:22 AM, Pradeep Cloudstack <
pradeepcloudst...@yahoo.com.invalid> wrote:

> I am working on a Proof-Of-Concept for a private cloud setup.
> Here is the organizational requirement:
> - Organization has Finance, Engineering and Marketing departments
> - Each Dept has a Cloudstack account
> - Each Dept has a separate network to which VMs are attached
> - Access to the Finance Dept Network should go through Firewall security
> - Access to the Marketing Dept Network shouldnot go through Firewall
> security
>
> - VMs in Engineering network can only communicate with each other but not
> with VMs in other networks
>
>
> The VPC feature doesnot help in this case as there are different accounts
> for each tenant
>
> Can you pls guide me on how I can achieve this ?
>
>
> -Pradeep
>
>
> ____
>  From: Jayapal Reddy Uradi 
> To: "" ; Pradeep
> Cloudstack 
> Sent: Wednesday, September 17, 2014 5:03 PM
> Subject: Re: Inter-network Communication
>
>
> Hi Pradeep,
>
> In cloudstack create network and launch vm in that to create router.
> To communicate between the networks depends on the network type in
> cloudstack.
>
> If you want multiple networks with single router use VPC networks/tiers
> and configure ACL between them.
>
> Isolated networks will one router per each network. If vm want to
> communicate to other network
> it can be done by  adding nic in that network or Create nat,firewall rules
> to reach vms in other network.
>
> Thanks,
> Jayapal
>
>
> On 17-Sep-2014, at 4:40 PM, Pradeep Cloudstack
> 
> wrote:
>
> > In OpenStack, there is a workflow wherein user can create multiple
> networks, then create a router
> > and attach to it some of the previously created networks to enable
> inter-network communication.
> >
> > What is the equivalent workflow in Cloudstack ?
> >
> > -Pradeep
>

Re: Inter-network Communication

[Pradeep Cloudstack]

I am working on a Proof-Of-Concept for a private cloud setup.
Here is the organizational requirement:
- Organization has Finance, Engineering and Marketing departments
- Each Dept has a Cloudstack account
- Each Dept has a separate network to which VMs are attached
- Access to the Finance Dept Network should go through Firewall security
- Access to the Marketing Dept Network shouldnot go through Firewall security

- VMs in Engineering network can only communicate with each other but not with 
VMs in other networks


The VPC feature doesnot help in this case as there are different accounts for 
each tenant

Can you pls guide me on how I can achieve this ?


-Pradeep



 From: Jayapal Reddy Uradi 
To: "" ; Pradeep 
Cloudstack  
Sent: Wednesday, September 17, 2014 5:03 PM
Subject: Re: Inter-network Communication
 

Hi Pradeep,

In cloudstack create network and launch vm in that to create router.
To communicate between the networks depends on the network type in cloudstack.

If you want multiple networks with single router use VPC networks/tiers and 
configure ACL between them.

Isolated networks will one router per each network. If vm want to communicate 
to other network
it can be done by  adding nic in that network or Create nat,firewall rules to 
reach vms in other network.

Thanks,
Jayapal


On 17-Sep-2014, at 4:40 PM, Pradeep Cloudstack 

wrote:

> In OpenStack, there is a workflow wherein user can create multiple networks, 
> then create a router
> and attach to it some of the previously created networks to enable 
> inter-network communication.
> 
> What is the equivalent workflow in Cloudstack ?
> 
> -Pradeep

Inter-network Communication

[Pradeep Cloudstack]

In OpenStack, there is a workflow wherein user can create multiple networks, 
then create a router
and attach to it some of the previously created networks to enable 
inter-network communication.

What is the equivalent workflow in Cloudstack ?

-Pradeep

Re: Access to non-oss builds

[Pradeep Cloudstack]

Thanks




 From: Ian Duffy 
To: Pradeep Cloudstack ; CloudStack Dev 
 
Sent: Friday, September 12, 2014 10:16 PM
Subject: Re: Access to non-oss builds
 

Hi Pradeep,

As far as I know there isn't an issue. The community supplied repos
includes non-oss libraries.

I believe its only an issue if they are hosted on Apache infrastructure.



On 12 Sep 2014 16:29, "Pradeep Cloudstack"
 wrote:

> We have a customer who is interested in trying out non-oss build (for eg:
> support for VMWare, SRX).Internally, we have built and tested the non-oss
> builds.
>
>
> What are the licensing implications in distributing such non-oss builds?
> Does it follow Apache license ?
> Is there any process involved ?
>
>
> -Pradeep
>

Access to non-oss builds

[Pradeep Cloudstack]

We have a customer who is interested in trying out non-oss build (for eg: 
support for VMWare, SRX).Internally, we have built and tested the non-oss 
builds.


What are the licensing implications in distributing such non-oss builds? Does 
it follow Apache license ?
Is there any process involved ?


-Pradeep

Re: CS 4.5/Master - Virtual Routers stuck in Starting state, Requires upgrade

[Pradeep Cloudstack]

My bad;
My cloudstack agent was still running the older version; upgraded the same and 
things are working fine now


-Pradeep






 From: Pradeep Cloudstack 
To: "dev@cloudstack.apache.org"  
Sent: Thursday, August 14, 2014 2:37 PM
Subject: Re: CS 4.5/Master - Virtual Routers stuck in Starting state, Requires 
upgrade
 


Hi Erik,
I used the latest from jenkins
http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-kvm.qcow2.bz2

Still, same issue

-Pradeep




 From: Erik Weber 
To: Pradeep Cloudstack ; dev 
 
Sent: Thursday, August 14, 2014 1:07 PM
Subject: Re: CS 4.5/Master - Virtual Routers stuck in Starting state, Requires 
upgrade
 

Use the newest from jenkins.

Erik
14. aug. 2014 09:34 skrev "Pradeep Cloudstack"
 følgende:


> I started the cloudstack management server from the master branch. After
> that, in the global settings, I set to
> false the value for "router.version.check".
>
> I am using  "systemvm64template-2014-01-14-master-kvm.qcow2.bz2" for
> system template.
>
> The Virtual Routers that are started are stuck in the "Starting" state and
> being marked as "Requires Upgrade"
>
> How do I overcome this
 issue ? Which system-vm-template should I use for
> KVM ?
>
> Also,
> select name,template_version from domain_router_view;
> shows NULL for template_version. I even tried manipulating this value to
> '4.3.0' which is the value for
> VirtualNetworkApplianceService.java.MinVRVersion.  But still, no luck
>
> -Pradeep
>

Re: CS 4.5/Master - Virtual Routers stuck in Starting state, Requires upgrade

[Pradeep Cloudstack]

Hi Erik,
I used the latest from jenkins
http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-kvm.qcow2.bz2

Still, same issue

-Pradeep




 From: Erik Weber 
To: Pradeep Cloudstack ; dev 
 
Sent: Thursday, August 14, 2014 1:07 PM
Subject: Re: CS 4.5/Master - Virtual Routers stuck in Starting state, Requires 
upgrade
 

Use the newest from jenkins.

Erik
14. aug. 2014 09:34 skrev "Pradeep Cloudstack"
 følgende:


> I started the cloudstack management server from the master branch. After
> that, in the global settings, I set to
> false the value for "router.version.check".
>
> I am using  "systemvm64template-2014-01-14-master-kvm.qcow2.bz2" for
> system template.
>
> The Virtual Routers that are started are stuck in the "Starting" state and
> being marked as "Requires Upgrade"
>
> How do I overcome this issue ? Which system-vm-template should I use for
> KVM ?
>
> Also,
> select name,template_version from domain_router_view;
> shows NULL for template_version. I even tried manipulating this value to
> '4.3.0' which is the value for
> VirtualNetworkApplianceService.java.MinVRVersion.  But still, no luck
>
> -Pradeep
>

CS 4.5/Master - Virtual Routers stuck in Starting state, Requires upgrade

[Pradeep Cloudstack]

I started the cloudstack management server from the master branch. After that, 
in the global settings, I set to 
false the value for "router.version.check".

I am using  "systemvm64template-2014-01-14-master-kvm.qcow2.bz2" for system 
template.

The Virtual Routers that are started are stuck in the "Starting" state and 
being marked as "Requires Upgrade"

How do I overcome this issue ? Which system-vm-template should I use for KVM ?

Also,
select name,template_version from domain_router_view; 
shows NULL for template_version. I even tried manipulating this value to 
'4.3.0' which is the value for
VirtualNetworkApplianceService.java.MinVRVersion.  But still, no luck

-Pradeep

Re: Review Request 23257: Cloudstack network-element plugin to orchestrate Juniper's switches (for L2 services)

[Pradeep Cloudstack]

Yes Hugo

We have addressed some of your comments

-Pradeep




 From: Hugo Trippaers 
To: Hugo Trippaers  
Cc: Pradeep HK ; cloudstack 
 
Sent: Wednesday, July 23, 2014 12:57 PM
Subject: Re: Review Request 23257: Cloudstack network-element plugin to 
orchestrate Juniper's switches (for L2 services)
 



> On July 3, 2014, 11:54 a.m., Hugo Trippaers wrote:
> > plugins/network-elements/juniper-networkguru/src/com/cloud/network/JuniperNDAPINaasServiceNetworkMapVO.java,
> >  line 43
> > 
> >
> >     Possible to fix this TODO before submitting?

Pradeep,

are you planning to continue working on this?


- Hugo


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23257/#review47287
---


On July 3, 2014, 11:54 a.m., Pradeep HK wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23257/
> ---
> 
> (Updated July 3, 2014, 11:54 a.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.



> 
> 
> Bugs: CLOUDSTACK-5398
>    https://issues.apache.org/jira/browse/CLOUDSTACK-5398
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Pls refer to the Design document available @
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+network-element+plugin+to+orchestrate+Juniper%27s+switches+%28for+L2+services%29
> 
> This feature is about a Cloudstack network-element plugin to orchestrate 
> Juniper's switches.
> 
> As a first-cut, we are focussing on L2 services and we will write a 
> NetworkGuru. As part of it's implement() method we will:
> (1)Create the required logical interfaces on the Juniper switches (EX,QFX)
> (2)Create the required VLANs on the Juniper switches (EX,QFX).
> (3)Configure VLAN membership on the interfaces
> 
> Our customers need this plugin in Cloudstack deployments to automatically 
> orchestrate the Juniper switches to create Virtual Networks.
> Without this plugin, there will be a manual intervention needed to configure 
> the switches (after figuring out the
> current configuration of the switch).
> 
> We have a Network Management Platform (called JUNOS SPACE) which is heavily 
> used by customers to orchestrate Juniper's networking devices.
> It also exposes REST-ful APIs for integration with 3rdParty tools.
> The proposed Juniper's Cloudstack network-element plugin leverages these 
> REST-ful APIs to appropriately orchestrate Juniper's switches to
> create Virtual Networks
> 
> 
> Diffs
> -
> 
>   client/pom.xml 29fef4f 
>   debian/cloudstack-management.install ea3f93b 
>   debian/rules 197e243 
>   deps/install-non-oss.sh 940bd32 
>   plugins/network-elements/juniper-networkguru/pom.xml PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/resources/META-INF/cloudstack/junipernetworkguru/module.properties
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/resources/META-INF/cloudstack/junipernetworkguru/spring-junipernetworkguru-context.xml
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/JuniperNetworkGuru.properties 
>PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/JuniperNDAPINaasServiceNetworkMapVO.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/guru/JuniperNetworkGuru.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/naas/dao/JuniperNDAPINaasServiceNetworkMapDao.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/naas/dao/JuniperNDAPINaasServiceNetworkMapDaoImpl.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/DeviceInterfacesMap.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/ELSJunosL2XMLConfigs.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/JuniperNDAPIConstants.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/JunosL2XMLConfigs.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/LLDPNeighbors.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/ShowHardwareModel.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/Utils.java
> PRE-CREATION 
>   
>plugins/network-elements/juniper-networkguru/src/com/cloud/network/utils/netconfOperations/NetconfOperations.java
> PRE-CREATION 
>   plugins/pom.xml b5e6a61 
> 
> Diff: https://reviews.apache.org/r/23257/diff/
> 
> 
> Testing

Re: NetworkOrchestrator selects 2 NetworkGurus at one time....

[Pradeep Cloudstack]

We have a use-case where we will patch an existing 4.3 installation with our 
plugin.
We are facing the same issue .
In 4.2, we used to disable the entry for ExternalNetworkGuru in
componentContext.xml as part of installing the patch.

How do we do this in 4.3 (on an existing installation) ?

-Pradeep




 From: Ritu Sabharwal 
To: "dev@cloudstack.apache.org" ; Chiradeep Vittal 
 
Cc: Sheng Yang ; Jayapal Reddy Uradi 
; Alena Prokharchyk 
 
Sent: Thursday, June 12, 2014 12:13 AM
Subject: RE: NetworkOrchestrator selects 2 NetworkGurus at one time
 

Thanks Chiradeep and Murali for the reply!

I am thinking of explicitly telling ExternalNetworkGuru to skip design when 
Brocade plugin is designing the network. I don't want to disable 
ExternalNetworkGuru from default build when Brocade plugin is not present so 
won't exclude it from the spring class loader.

Thanks & Regards,
Ritu S.




-Original Message-
From: Murali Reddy [mailto:murali.re...@citrix.com] 
Sent: Tuesday, June 10, 2014 10:54 PM
To: Chiradeep Vittal; dev@cloudstack.apache.org
Cc: Sheng Yang; Jayapal Reddy Uradi; Alena Prokharchyk
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

This is know design issue. Unlike service orchestration (which has prescriptive 
way to tell which network elements to be called for with network offerings ) 
there is no such logic for network design. Orchestrator just loops through all 
the network guru's asking to design the network which can results in one or 
more networks. Hugo did a cleanup [1] but I believe it was not merged as there 
was no consensus. There is 1-1 mapping between isolation type and Guru but In 
this case both Brocade Guru and ExternalNetworkGuru will attempt to design the 
VLAN isolated networks.

One in-elegent solution is to hard code ExternalGuestNetworu guru to skip 
network deign when Brocade plug-in is supposed to do design the network. Other 
option could be exclude ExternalNetworkGuru bean from spring class loader.

[1] https://www.mail-archive.com/dev@cloudstack.apache.org/msg17344.html

From: Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>
Date: Wednesday, 11 June 2014 6:24 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Cc: Sheng Yang mailto:sheng.y...@citrix.com>>, Murali 
Reddy mailto:murali.re...@citrix.com>>, Jayapal Reddy 
Uradi mailto:jayapalreddy.ur...@citrix.com>>, 
Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

That is strange. Looks like a bug to me. That is because the 
ExternalGuestNetworkGuru returns 'true' for canHandle.

From: Ritu Sabharwal mailto:rsabh...@brocade.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, June 10, 2014 at 11:02 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: NetworkOrchestrator selects 2 NetworkGurus at one time

Hi,

I am writing a Network Guru for automatically orchestrating Brocade VDX 
switches to provide tenant isolation via VLAN. In my NetworkGuru, I have 
implemented the canHandle() method for Guest isolated network in Advanced zone 
using VLAN isolation. When the NetworkOrchestrator selects the NetworkGuru, it 
selects my NetworkGuru and the ExternalGuestNetworkGuru also and I see 2 
networks created. How do I make sure that ExternalGuestNetworkGuru is not 
selected by NetworkOrchestrator.

Thanks & Regards,
Ritu S.

Re: CS 4.3 - Registering network-element plugin

[Pradeep Cloudstack]

Hi Punith,
we will have this file under /etc/cloudstack/management
Customer can also edit this file


-Pradeep




 From: Punith S 
To: cloudstack ; Pradeep Cloudstack 
 
Sent: Tuesday, June 24, 2014 4:08 PM
Subject: Re: CS 4.3 - Registering network-element plugin
 

hi pradeep,

you can put your custom key value pairs in your *-context.xml inside your
bean

for example

        
        
        
        
        
        
        
  

also i'm curious to know how to move these properties out of the jar ?, can
you please elaborate.

thanks.



On Tue, Jun 24, 2014 at 4:02 PM, Pradeep Cloudstack <
pradeepcloudst...@yahoo.com.invalid> wrote:

> Hi Punith,
> yes; the properties file contains custom key value pairs
>
> We have decided move this file out of our jar. So, no issues now
>
> -Pradeep
>
>
>
> ____
>  From: Punith S 
> To: cloudstack ; Pradeep Cloudstack <
> pradeepcloudst...@yahoo.com>
> Sent: Tuesday, June 24, 2014 3:52 PM
> Subject: Re: CS 4.3 - Registering network-element plugin
>
>
> hi pradeep,
>
> does the JuniperNetworkGuru.properties file contain your custom key value
> pairs to be used in the plugin ?
>
> thanks.
>
>
> On Tue, Jun 24, 2014 at 2:56 PM, Pradeep Cloudstack <
> pradeepcloudst...@yahoo.com.invalid> wrote:
>
> > Hi Punith,
> > the war contains the jar file. Also, the names are correct.
> >
> > In out network-element pom.xml file, we had made entries to ensure that a
> > property file
> > is bundled with the jar
> >
> > ***
> >   
> >      
> >        
> >          src
> >          false
> >          
> >                  JuniperNetworkGuru.properties
> >              
> >        
> >      
> >    
> > ***
> >
> > This seems to be causing the issue. If I remove this entry, I see that
> the
> > spring.xml and module.properties
> > are bundled in the jar, but our JuniperNetworkGuru.properties will not
> get
> > bundled
> >
> > -Pradeep
> >
> >
> >
> > 
> >  From: Punith S 
> > To: cloudstack ; Pradeep Cloudstack <
> > pradeepcloudst...@yahoo.com>
> > Sent: Tuesday, June 24, 2014 12:55 PM
> > Subject: Re: CS 4.3 - Registering network-element plugin
> >
> >
> > hi pradeep,
> >
> > can you make sure your jar is present in the cloud war.
> > to make this happen you have to register the dependency in the client
> > pom.xml file.
> >
> > also you need to register your plugin in the plugin pom.xml file and make
> > sure the provider name matches.
> >
> > thanks.
> >
> >
> >
> > On Tue, Jun 24, 2014 at 12:38 PM, Pradeep Cloudstack <
> > pradeepcloudst...@yahoo.com.invalid> wrote:
> >
> > > Thanks Punith.
> > > We had tried this.
> > > However the jar file that is built didnot include the
> > spring-*-context.xml
> > > and module.properties
> > > as a result of which our plugin didnot get registered.
> > >
> > > We followed the approach that was taken for vxlan and created artifacts
> > on
> > > similar lines.
> > >
> > > Can you pls help on what we are missing ?
> > >
> > >
> > > -Pradeep
> > >
> > >
> > >
> > > ____
> > >  From: Punith S 
> > > To: cloudstack ; Pradeep Cloudstack <
> > > pradeepcloudst...@yahoo.com>
> > > Sent: Tuesday, June 24, 2014 12:11 PM
> > > Subject: Re: CS 4.3 - Registering network-element plugin
> > >
> > >
> > > hi pradeep,
> > >
> > > the spring framework has been modularized in 4.3 onwards,
> > > this link might help you in registering the new plugin.
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug-ins%2C+Modules%2C+and+Extensions
> > >
> > > thanks,
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Jun 24, 2014 at 11:57 AM, Pradeep Cloudstack <
> > > pradeepcloudst...@yahoo.com.invalid> wrote:
> > >
> > > > Hi team,
> > > > I need some help in registering network-element plugin in a 4.3
> > > > installation.
> > > >
> > > > In 4.2 release, we used to make entries in componentContext.xml.
> > > >
> > > > However in 4.3, looks like there is a NetworkGuru Registry.
> > > > How do we register our plugin here?
> > > >
> > > > -Pradeep
> > > >
> > >
> > >
> > >
> > > --
> > > regards,



>
>
>
> >
> > >
> > > punith s
> > > cloudbyte.com
> > >
> >
> >
> >
> > --
> > regards,
> >
> > punith s
> > cloudbyte.com
> >
>
>
>
> --
> regards,
>
> punith s
> cloudbyte.com
>



-- 
regards,

punith s
cloudbyte.com

Re: CS 4.3 - Registering network-element plugin

[Pradeep Cloudstack]

Hi Punith,
yes; the properties file contains custom key value pairs

We have decided move this file out of our jar. So, no issues now

-Pradeep




 From: Punith S 
To: cloudstack ; Pradeep Cloudstack 
 
Sent: Tuesday, June 24, 2014 3:52 PM
Subject: Re: CS 4.3 - Registering network-element plugin
 

hi pradeep,

does the JuniperNetworkGuru.properties file contain your custom key value
pairs to be used in the plugin ?

thanks.


On Tue, Jun 24, 2014 at 2:56 PM, Pradeep Cloudstack <
pradeepcloudst...@yahoo.com.invalid> wrote:

> Hi Punith,
> the war contains the jar file. Also, the names are correct.
>
> In out network-element pom.xml file, we had made entries to ensure that a
> property file
> is bundled with the jar
>
> ***
>   
>      
>        
>          src
>          false
>          
>                  JuniperNetworkGuru.properties
>              
>        
>      
>    
> ***
>
> This seems to be causing the issue. If I remove this entry, I see that the
> spring.xml and module.properties
> are bundled in the jar, but our JuniperNetworkGuru.properties will not get
> bundled
>
> -Pradeep
>
>
>
> 
>  From: Punith S 
> To: cloudstack ; Pradeep Cloudstack <
> pradeepcloudst...@yahoo.com>
> Sent: Tuesday, June 24, 2014 12:55 PM
> Subject: Re: CS 4.3 - Registering network-element plugin
>
>
> hi pradeep,
>
> can you make sure your jar is present in the cloud war.
> to make this happen you have to register the dependency in the client
> pom.xml file.
>
> also you need to register your plugin in the plugin pom.xml file and make
> sure the provider name matches.
>
> thanks.
>
>
>
> On Tue, Jun 24, 2014 at 12:38 PM, Pradeep Cloudstack <
> pradeepcloudst...@yahoo.com.invalid> wrote:
>
> > Thanks Punith.
> > We had tried this.
> > However the jar file that is built didnot include the
> spring-*-context.xml
> > and module.properties
> > as a result of which our plugin didnot get registered.
> >
> > We followed the approach that was taken for vxlan and created artifacts
> on
> > similar lines.
> >
> > Can you pls help on what we are missing ?
> >
> >
> > -Pradeep
> >
> >
> >
> > 
> >  From: Punith S 
> > To: cloudstack ; Pradeep Cloudstack <
> > pradeepcloudst...@yahoo.com>
> > Sent: Tuesday, June 24, 2014 12:11 PM
> > Subject: Re: CS 4.3 - Registering network-element plugin
> >
> >
> > hi pradeep,
> >
> > the spring framework has been modularized in 4.3 onwards,
> > this link might help you in registering the new plugin.
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug-ins%2C+Modules%2C+and+Extensions
> >
> > thanks,
> >
> >
> >
> >
> >
> > On Tue, Jun 24, 2014 at 11:57 AM, Pradeep Cloudstack <
> > pradeepcloudst...@yahoo.com.invalid> wrote:
> >
> > > Hi team,
> > > I need some help in registering network-element plugin in a 4.3
> > > installation.
> > >
> > > In 4.2 release, we used to make entries in componentContext.xml.
> > >
> > > However in 4.3, looks like there is a NetworkGuru Registry.
> > > How do we register our plugin here?
> > >
> > > -Pradeep
> > >
> >
> >
> >
> > --
> > regards,



>
> >
> > punith s
> > cloudbyte.com
> >
>
>
>
> --
> regards,
>
> punith s
> cloudbyte.com
>



-- 
regards,

punith s
cloudbyte.com

Re: CS 4.3 - Registering network-element plugin

[Pradeep Cloudstack]

Hi Punith,
the war contains the jar file. Also, the names are correct.

In out network-element pom.xml file, we had made entries to ensure that a 
property file
is bundled with the jar

***  
  
 
   
 src
 false
 
 JuniperNetworkGuru.properties
 
   
 
   
***

This seems to be causing the issue. If I remove this entry, I see that the 
spring.xml and module.properties
are bundled in the jar, but our JuniperNetworkGuru.properties will not get 
bundled

-Pradeep




 From: Punith S 
To: cloudstack ; Pradeep Cloudstack 
 
Sent: Tuesday, June 24, 2014 12:55 PM
Subject: Re: CS 4.3 - Registering network-element plugin
 

hi pradeep,

can you make sure your jar is present in the cloud war.
to make this happen you have to register the dependency in the client
pom.xml file.

also you need to register your plugin in the plugin pom.xml file and make
sure the provider name matches.

thanks.



On Tue, Jun 24, 2014 at 12:38 PM, Pradeep Cloudstack <
pradeepcloudst...@yahoo.com.invalid> wrote:

> Thanks Punith.
> We had tried this.
> However the jar file that is built didnot include the spring-*-context.xml
> and module.properties
> as a result of which our plugin didnot get registered.
>
> We followed the approach that was taken for vxlan and created artifacts on
> similar lines.
>
> Can you pls help on what we are missing ?
>
>
> -Pradeep
>
>
>
> ________
>  From: Punith S 
> To: cloudstack ; Pradeep Cloudstack <
> pradeepcloudst...@yahoo.com>
> Sent: Tuesday, June 24, 2014 12:11 PM
> Subject: Re: CS 4.3 - Registering network-element plugin
>
>
> hi pradeep,
>
> the spring framework has been modularized in 4.3 onwards,
> this link might help you in registering the new plugin.
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug-ins%2C+Modules%2C+and+Extensions
>
> thanks,
>
>
>
>
>
> On Tue, Jun 24, 2014 at 11:57 AM, Pradeep Cloudstack <
> pradeepcloudst...@yahoo.com.invalid> wrote:
>
> > Hi team,
> > I need some help in registering network-element plugin in a 4.3
> > installation.
> >
> > In 4.2 release, we used to make entries in componentContext.xml.
> >
> > However in 4.3, looks like there is a NetworkGuru Registry.
> > How do we register our plugin here?
> >
> > -Pradeep
> >
>
>
>
> --
> regards,

>
> punith s
> cloudbyte.com
>



-- 
regards,

punith s
cloudbyte.com

Re: CS 4.3 - Registering network-element plugin

[Pradeep Cloudstack]

Thanks Punith.
We had tried this.
However the jar file that is built didnot include the spring-*-context.xml and 
module.properties
as a result of which our plugin didnot get registered.

We followed the approach that was taken for vxlan and created artifacts on 
similar lines.

Can you pls help on what we are missing ?


-Pradeep




 From: Punith S 
To: cloudstack ; Pradeep Cloudstack 
 
Sent: Tuesday, June 24, 2014 12:11 PM
Subject: Re: CS 4.3 - Registering network-element plugin
 

hi pradeep,

the spring framework has been modularized in 4.3 onwards,
this link might help you in registering the new plugin.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug-ins%2C+Modules%2C+and+Extensions

thanks,





On Tue, Jun 24, 2014 at 11:57 AM, Pradeep Cloudstack <
pradeepcloudst...@yahoo.com.invalid> wrote:

> Hi team,
> I need some help in registering network-element plugin in a 4.3
> installation.
>
> In 4.2 release, we used to make entries in componentContext.xml.
>
> However in 4.3, looks like there is a NetworkGuru Registry.
> How do we register our plugin here?
>
> -Pradeep
>



-- 
regards,

punith s
cloudbyte.com

CS 4.3 - Registering network-element plugin

[Pradeep Cloudstack]

Hi team,
I need some help in registering network-element plugin in a 4.3 installation.

In 4.2 release, we used to make entries in componentContext.xml.

However in 4.3, looks like there is a NetworkGuru Registry.
How do we register our plugin here?

-Pradeep

(2nd try) Can not find systemvmiso - CS42 with XenServer

[Pradeep Cloudstack]

Any pointers on debugging this ?




 From: Pradeep Cloudstack 
To: "dev@cloudstack.apache.org"  
Sent: Monday, May 5, 2014 2:48 PM
Subject: Can not find systemvmiso - CS42 with XenServer
 


I am running CS42 from my development environment. I am managing XenServer 6.2 
from my CS mgmt server.
When I try to create instances, I am getting this error:
**
RuntimeException due to com.cloud.utils.exception.CloudRuntimeException: can 
not find systemvmiso
com.cloud.utils.exception.CloudRuntimeException: can not find systemvmiso
    at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.createPatchVbd(CitrixResourceBase.java:1439)
    at
 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1633)

**

I checked the following:
(1)I have systemvm.iso at the relative path to the patch file
(2)I have /usr/bin/vhd-util  (with executable permission)
(3)I have done cloud-install-sys-tmplt for hypervisor type - xenserver


Any help on debugging this further will be greatly appreciated

-Pradeep

Can not find systemvmiso - CS42 with XenServer

[Pradeep Cloudstack]

I am running CS42 from my development environment. I am managing XenServer 6.2 
from my CS mgmt server.
When I try to create instances, I am getting this error:
**
RuntimeException due to com.cloud.utils.exception.CloudRuntimeException: can 
not find systemvmiso
com.cloud.utils.exception.CloudRuntimeException: can not find systemvmiso
    at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.createPatchVbd(CitrixResourceBase.java:1439)
    at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1633)

**

I checked the following:
(1)I have systemvm.iso at the relative path to the patch file
(2)I have /usr/bin/vhd-util  (with executable permission)
(3)I have done cloud-install-sys-tmplt for hypervisor type - xenserver


Any help on debugging this further will be greatly appreciated

-Pradeep

Re: Issue with multiple hypervisor in Cloudstack 4.2

[Pradeep Cloudstack]

My bad; I was using wrong template (one that was meant for KVM)

-pradeep





 From: Pradeep Cloudstack 
To: "dev@cloudstack.apache.org"  
Sent: Monday, April 14, 2014 2:43 PM
Subject: Issue with multiple hypervisor in Cloudstack 4.2 
 


Hi,

I have a Cloustack 4.2 deployment. I created a Advanced zone and there I chose 
the Hypervisor type as KVM.

Later I created a cluster for XenServer hypervisor type and added a XenServer 
to it. Now I want to create a VM on the
XenServer from Cloudstack UI.

I created appropriate Host Tags and Compute Offerings. I now tried to create an 
Instance by choosing the Compute Offering relevant to XenServer. However the VM 
creation is failing.

When I look at the logs, I find that:
(1)deployVirtualMachine command is being invoked with hypervisor=KVM

(2)In the logs I see  - "Cluster: 2 has HyperVisorType that does not match the 
VM, skipping this cluster" meaning it is skipping the Xen cluster because the 
hypervisorType parameter has value as KVM

Any idea why is the hypervisorType being passed as KVM? How do I over come this?

-Pradeep

Issue with multiple hypervisor in Cloudstack 4.2

[Pradeep Cloudstack]

Hi,

I have a Cloustack 4.2 deployment. I created a Advanced zone and there I chose 
the Hypervisor type as KVM.

Later I created a cluster for XenServer hypervisor type and added a XenServer 
to it. Now I want to create a VM on the
XenServer from Cloudstack UI.

I created appropriate Host Tags and Compute Offerings. I now tried to create an 
Instance by choosing the Compute Offering relevant to XenServer. However the VM 
creation is failing.

When I look at the logs, I find that:
(1)deployVirtualMachine command is being invoked with hypervisor=KVM

(2)In the logs I see  - "Cluster: 2 has HyperVisorType that does not match the 
VM, skipping this cluster" meaning it is skipping the Xen cluster because the 
hypervisorType parameter has value as KVM

Any idea why is the hypervisorType being passed as KVM? How do I over come this?

-Pradeep

Cloudstack support for Xen (on Ubuntu)

[Pradeep Cloudstack]

I have a server running Ubuntu 13.04. I am planning to install Xen Hypervisor 
on that
(https://help.ubuntu.com/community/XenProposed#Xen_and_XAPI)

Can I then have it managed (as a host) by Cloudstack 4.2 ?

-pradeep

Re: 4.4 Feature Freeze

[Pradeep Cloudstack]

Yes Mike

-Pradeep





 From: Mike Tutkowski 
To: "dev@cloudstack.apache.org" ; Pradeep Cloudstack 
 
Cc: Chiradeep Vittal ; Animesh Chaturvedi 
 
Sent: Thursday, March 20, 2014 10:34 AM
Subject: Re: 4.4 Feature Freeze
 

It looks like your code is exclusively related to a network plug-in, is
that correct? In other words, you do not modify any CloudStack core code,
but rather solely interface with CloudStack via a plug-in interface.


On Wed, Mar 19, 2014 at 10:50 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hugo can talk about this in more depth, but the idea is that you develop
> your feature in your own branch (every now and then rebasing your work on
> top of what's been put into master to keep it current).
>
> At some point, there is what we call Feature Freeze (that was last week
> Friday).
>
> On this day (ideally beforehand, if reasonably possible), all new features
> must be taken from your branch and put into the master branch. At some
> point in the day, a new branch - in this case, called 4.4 - is made and
> then master is used for the release to follow 4.4.
>
> After Feature Freeze, all changes to 4.4 should be accompanied by a JIRA
> ticket (ideally this would always be the case) and most of our 4.4 effort
> is placed into testing what we have versus adding new features to it.
>
>
> On Wed, Mar 19, 2014 at 10:44 PM, Pradeep Cloudstack <
> pradeepcloudst...@yahoo.com> wrote:
>
>> Hi Sudha,Mike,Hogo,
>> this is a new feature (and I am also new to the process)
>> So I am not quite getting the meaning of "All merges are done last week".
>>
>> -Pradeep
>>
>>
>>
>>
>> 
>>  From: Sudha Ponnaganti 
>> To: "dev@cloudstack.apache.org" ; Pradeep
>> Cloudstack ; Chiradeep Vittal <
>> chiradeep.vit...@citrix.com>; Animesh Chaturvedi <
>> animesh.chaturv...@citrix.com>
>> Sent: Thursday, March 20, 2014 10:04 AM
>> Subject: RE: 4.4 Feature Freeze
>>
>>
>> It is too late already - All merges are done last week. It can go in to
>> 4.5 (Master)
>>
>>
>> -Original Message-
>> From: Pradeep Cloudstack [mailto:pradeepcloudst...@yahoo.com]
>> Sent: Wednesday, March 19, 2014 9:30 PM
>> To: dev@cloudstack.apache.org; Chiradeep Vittal; Animesh Chaturvedi
>> Subject: Re: 4.4 Feature Freeze
>>
>> Hi Mike,
>> the following feature
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=36274178
>> is there under 4.4 Design documents.
>>
>> How do I check if this feature is part of 4.4 ?
>>
>> I had sent out a Proposal sometime back about this feature
>>
>> -Pradeep
>>
>>
>>
>>
>> 
>> From: Mike Tutkowski 
>> To: "dev@cloudstack.apache.org" ; Pradeep
>> Cloudstack 
>> Sent: Thursday, March 20, 2014 9:52 AM
>> Subject: Re: 4.4 Feature Freeze
>>
>>
>> I'm not sure if we have a "code freeze" per se, but "feature freeze" was
>> last week Friday. Technically all features that are to go into 4.4 should
>> have been in master on that day when the 4.4 branch was cut.
>>
>>
>> On Wed, Mar 19, 2014 at 10:01 PM, Pradeep Cloudstack <
>> pradeepcloudst...@yahoo.com> wrote:
>>
>> > What is the code-freeze date for 4.4 ?
>> > I need to commit the following feature -
>> >
>> >
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=36274178
>> >
>> >
>> > -Pradeep
>> >
>> >
>> >
>> >
>> >
>> > On Friday, March 14, 2014 8:13 PM, Sudha Ponnaganti <
>> > sudha.ponnaga...@citrix.com> wrote:
>> >
>> > Other alternative is to block further check-ins till blocking issue is
>> > fixed. As long as BVTs are good then it can be opened up for further
>> check
>> > ins.  Just a suggestion.
>> >
>> >
>> > -Original Message-
>> > From: Marcus [mailto:shadow...@gmail.com]
>> > Sent: Friday, March 14, 2014 7:40 AM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: 4.4 Feature Freeze
>> >
>> > It may even just be a behavioral change or something simple I missed
>> that
>> > is now required with a recent check-in. Obviously I don't feel
>> comfortable
>> > merging in my feature branch though when I pull from master and can no
>> > longer run my own feature tests.
>> >
>> > On Fri, 

Re: 4.4 Feature Freeze

[Pradeep Cloudstack]

Hi Sudha,Mike,Hogo,
this is a new feature (and I am also new to the process)
So I am not quite getting the meaning of "All merges are done last week".

-Pradeep





 From: Sudha Ponnaganti 
To: "dev@cloudstack.apache.org" ; Pradeep Cloudstack 
; Chiradeep Vittal ; 
Animesh Chaturvedi  
Sent: Thursday, March 20, 2014 10:04 AM
Subject: RE: 4.4 Feature Freeze
 

It is too late already - All merges are done last week. It can go in to 4.5 
(Master)


-Original Message-
From: Pradeep Cloudstack [mailto:pradeepcloudst...@yahoo.com] 
Sent: Wednesday, March 19, 2014 9:30 PM
To: dev@cloudstack.apache.org; Chiradeep Vittal; Animesh Chaturvedi
Subject: Re: 4.4 Feature Freeze

Hi Mike,
the following feature
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=36274178
is there under 4.4 Design documents.

How do I check if this feature is part of 4.4 ?

I had sent out a Proposal sometime back about this feature

-Pradeep 





From: Mike Tutkowski 
To: "dev@cloudstack.apache.org" ; Pradeep Cloudstack 
 
Sent: Thursday, March 20, 2014 9:52 AM
Subject: Re: 4.4 Feature Freeze


I'm not sure if we have a "code freeze" per se, but "feature freeze" was
last week Friday. Technically all features that are to go into 4.4 should
have been in master on that day when the 4.4 branch was cut.


On Wed, Mar 19, 2014 at 10:01 PM, Pradeep Cloudstack <
pradeepcloudst...@yahoo.com> wrote:

> What is the code-freeze date for 4.4 ?
> I need to commit the following feature -
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=36274178
>
>
> -Pradeep
>
>
>
>
>
> On Friday, March 14, 2014 8:13 PM, Sudha Ponnaganti <
> sudha.ponnaga...@citrix.com> wrote:
>
> Other alternative is to block further check-ins till blocking issue is
> fixed. As long as BVTs are good then it can be opened up for further check
> ins.  Just a suggestion.
>
>
> -Original Message-
> From: Marcus [mailto:shadow...@gmail.com]
> Sent: Friday, March 14, 2014 7:40 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
>
> It may even just be a behavioral change or something simple I missed that
> is now required with a recent check-in. Obviously I don't feel comfortable
> merging in my feature branch though when I pull from master and can no
> longer run my own feature tests.
>
> On Fri, Mar 14, 2014 at 8:35 AM, Marcus  wrote:
> > I'm not sure what the offending ones are at the moment, and there was
> > recently a  feature merge that was not squashed, so it might be a
> > little difficult to weed through.
> >
> > On Mar 14, 2014 7:45 AM, "Sudha Ponnaganti"
> > 
> > wrote:
> >>
> >> Can the offending check-ins be reverted or master be blocked for
> >> further check-ins till blocking issue is fixed.
> >> Talluri is running BVTs and can that be taken as basic passing
> >> criteria to re-enable check-ins.
> >>
> >> -Original Message-
> >> From: Marcus [mailto:shadow...@gmail.com]
> >> Sent: Friday, March 14, 2014 6:36 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: 4.4 Feature Freeze
> >>
> >> Will be doing it today, however it seems that there have been some
> >> new issues that have cropped up in master that break basic
> functionality.
> >> I'm not sure if anyone should merge or not while that is the case.  I
> >> was attempting to validate that the latest merges played well in my
> >> branch, but I couldn't even get a vm running with the current master,
> >> and I see that while I was sleeping others have reported some of the
> >> issues I was seeing as well.
> >>
> >> On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
> >> > On 11.03.2014 15:28, Hugo Trippaers wrote:
> >> >>
> >> >> Hey guys,
> >> >>
> >> >> I didn't go and tally all the +1s and -1s for the shift of the
> >> >> feature freeze, but with so many reactions i feel sticking to the
> >> >> schedule is the only way to go. We should only change dates if
> >> >> there is a consensus and there clearly is none at the moment.
> >> >> Let's take this discussion to the 4.5 release if we need to or
> >> >> focus on doing a high quality release for 4.4 so we can focus on
> >> >> features again in 4.4
> >> >>
> >> >> This means that the feature freeze would be this friday and i
> >> >> intend to cut the 4.4 branch around 14:00 CET
> >> >>
>

Re: 4.4 Feature Freeze

[Pradeep Cloudstack]

Hi Mike,
the following feature
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=36274178
is there under 4.4 Design documents.

How do I check if this feature is part of 4.4 ?

I had sent out a Proposal sometime back about this feature

-Pradeep 





 From: Mike Tutkowski 
To: "dev@cloudstack.apache.org" ; Pradeep Cloudstack 
 
Sent: Thursday, March 20, 2014 9:52 AM
Subject: Re: 4.4 Feature Freeze
 

I'm not sure if we have a "code freeze" per se, but "feature freeze" was
last week Friday. Technically all features that are to go into 4.4 should
have been in master on that day when the 4.4 branch was cut.


On Wed, Mar 19, 2014 at 10:01 PM, Pradeep Cloudstack <
pradeepcloudst...@yahoo.com> wrote:

> What is the code-freeze date for 4.4 ?
> I need to commit the following feature -
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=36274178
>
>
> -Pradeep
>
>
>
>
>
> On Friday, March 14, 2014 8:13 PM, Sudha Ponnaganti <
> sudha.ponnaga...@citrix.com> wrote:
>
> Other alternative is to block further check-ins till blocking issue is
> fixed. As long as BVTs are good then it can be opened up for further check
> ins.  Just a suggestion.
>
>
> -Original Message-
> From: Marcus [mailto:shadow...@gmail.com]
> Sent: Friday, March 14, 2014 7:40 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
>
> It may even just be a behavioral change or something simple I missed that
> is now required with a recent check-in. Obviously I don't feel comfortable
> merging in my feature branch though when I pull from master and can no
> longer run my own feature tests.
>
> On Fri, Mar 14, 2014 at 8:35 AM, Marcus  wrote:
> > I'm not sure what the offending ones are at the moment, and there was
> > recently a  feature merge that was not squashed, so it might be a
> > little difficult to weed through.
> >
> > On Mar 14, 2014 7:45 AM, "Sudha Ponnaganti"
> > 
> > wrote:
> >>
> >> Can the offending check-ins be reverted or master be blocked for
> >> further check-ins till blocking issue is fixed.
> >> Talluri is running BVTs and can that be taken as basic passing
> >> criteria to re-enable check-ins.
> >>
> >> -Original Message-
> >> From: Marcus [mailto:shadow...@gmail.com]
> >> Sent: Friday, March 14, 2014 6:36 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: 4.4 Feature Freeze
> >>
> >> Will be doing it today, however it seems that there have been some
> >> new issues that have cropped up in master that break basic
> functionality.
> >> I'm not sure if anyone should merge or not while that is the case.  I
> >> was attempting to validate that the latest merges played well in my
> >> branch, but I couldn't even get a vm running with the current master,
> >> and I see that while I was sleeping others have reported some of the
> >> issues I was seeing as well.
> >>
> >> On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
> >> > On 11.03.2014 15:28, Hugo Trippaers wrote:
> >> >>
> >> >> Hey guys,
> >> >>
> >> >> I didn't go and tally all the +1s and -1s for the shift of the
> >> >> feature freeze, but with so many reactions i feel sticking to the
> >> >> schedule is the only way to go. We should only change dates if
> >> >> there is a consensus and there clearly is none at the moment.
> >> >> Let's take this discussion to the 4.5 release if we need to or
> >> >> focus on doing a high quality release for 4.4 so we can focus on
> >> >> features again in 4.4
> >> >>
> >> >> This means that the feature freeze would be this friday and i
> >> >> intend to cut the 4.4 branch around 14:00 CET
> >> >>
> >> >> As we have a 72 hour window for MERGE requests, please make sure
> >> >> they are in today (if the feature is ready).
> >> >>
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Hugo
> >> >
> >> >
> >> > Can someone confirm if this has made it in?
> >> > https://issues.apache.org/jira/browse/CLOUDSTACK-6181
> >> >
> >> > Marcus requested the MERGE a couple of days ago.
> >> > http://www.mail-archive.com/dev@cloudstack.apache.org/msg24793.html
> >> >
> >> > Lucian
> >> >
> >> > --
> >> > Sent from the Delta quadrant using Borg technology!
> >> >
> >> > Nux!
> >> > www.nux.ro
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>

*(tm)*

Re: 4.4 Feature Freeze

[Pradeep Cloudstack]

What is the code-freeze date for 4.4 ?
I need to commit the following feature -

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=36274178


-Pradeep





On Friday, March 14, 2014 8:13 PM, Sudha Ponnaganti 
 wrote:
 
Other alternative is to block further check-ins till blocking issue is fixed. 
As long as BVTs are good then it can be opened up for further check ins.  Just 
a suggestion. 


-Original Message-
From: Marcus [mailto:shadow...@gmail.com] 
Sent: Friday, March 14, 2014 7:40 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze

It may even just be a behavioral change or something simple I missed that is 
now required with a recent check-in. Obviously I don't feel comfortable merging 
in my feature branch though when I pull from master and can no longer run my 
own feature tests.

On Fri, Mar 14, 2014 at 8:35 AM, Marcus  wrote:
> I'm not sure what the offending ones are at the moment, and there was 
> recently a  feature merge that was not squashed, so it might be a 
> little difficult to weed through.
>
> On Mar 14, 2014 7:45 AM, "Sudha Ponnaganti" 
> 
> wrote:
>>
>> Can the offending check-ins be reverted or master be blocked for 
>> further check-ins till blocking issue is fixed.
>> Talluri is running BVTs and can that be taken as basic passing 
>> criteria to re-enable check-ins.
>>
>> -Original Message-
>> From: Marcus [mailto:shadow...@gmail.com]
>> Sent: Friday, March 14, 2014 6:36 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>>
>> Will be doing it today, however it seems that there have been some 
>> new issues that have cropped up in master that break basic functionality.
>> I'm not sure if anyone should merge or not while that is the case.  I 
>> was attempting to validate that the latest merges played well in my 
>> branch, but I couldn't even get a vm running with the current master, 
>> and I see that while I was sleeping others have reported some of the 
>> issues I was seeing as well.
>>
>> On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
>> > On 11.03.2014 15:28, Hugo Trippaers wrote:
>> >>
>> >> Hey guys,
>> >>
>> >> I didn't go and tally all the +1s and -1s for the shift of the 
>> >> feature freeze, but with so many reactions i feel sticking to the 
>> >> schedule is the only way to go. We should only change dates if 
>> >> there is a consensus and there clearly is none at the moment. 
>> >> Let's take this discussion to the 4.5 release if we need to or 
>> >> focus on doing a high quality release for 4.4 so we can focus on 
>> >> features again in 4.4
>> >>
>> >> This means that the feature freeze would be this friday and i 
>> >> intend to cut the 4.4 branch around 14:00 CET
>> >>
>> >> As we have a 72 hour window for MERGE requests, please make sure 
>> >> they are in today (if the feature is ready).
>> >>
>> >>
>> >> Cheers,
>> >>
>> >> Hugo
>> >
>> >
>> > Can someone confirm if this has made it in?
>> > https://issues.apache.org/jira/browse/CLOUDSTACK-6181
>> >
>> > Marcus requested the MERGE a couple of days ago.
>> > http://www.mail-archive.com/dev@cloudstack.apache.org/msg24793.html
>> >
>> > Lucian
>> >
>> > --
>> > Sent from the Delta quadrant using Borg technology!
>> >
>> > Nux!
>> > www.nux.ro

Re: Create VM - find out the NIC on KVM host connected to a Network switch

[Pradeep Cloudstack]

I have the NetworkGuru plugin(for orchestarting Juniper Switches) in the 
Management Server.
(1)Create and Add first VM to Network. The Network is assigned a VLAN ID.
(2)The implement() method of NetworkGuru plugin is invoked
Here, I need to figure out the the vNIC to physical NIC mapping for this VM on 
the KVM host. By getting
the physical NIC information, I can figure out the switch-port it is connected 
to using LLDP information on the switch

-Pradeep





On Tuesday, December 24, 2013 4:26 AM, Chiradeep Vittal 
 wrote:
 
Why do you need this information on the MS? Can you detail the steps of the 
algorithm you are trying to design?
E.g., 
AddVMtoNetwork:
Step 1:
Step 2:
Step 3: Aha. Here's where I need this info


From: Pradeep Cloudstack 
Reply-To: Pradeep Cloudstack 
Date: Sunday, December 22, 2013 10:43 PM
To: Chiradeep Vittal , "dev@cloudstack.apache.org" 

Subject: Re: Create VM - find out the NIC on KVM host connected to a Network 
switch


That is fine. But how do we convey this information to the Mgmt Server ?
Without making any enhancements to MgmtSvr/Agent , is it possible to achieve 
this?

-Pradeep





On Saturday, December 21, 2013 4:19 AM, Chiradeep Vittal 
 wrote:

On the KVM host you could parse the output of 'brctl show', but that is
awkward to parse.
Or you might be able to iterate through /sys/devices/virtual/net/* and
work backwards from that.


On 12/19/13 10:16 PM, "Pradeep Cloudstack" 
wrote:

>Hi Chiradeep,
>the LLDP output on the switch looks something like
>
>*
>Local Interface    Parent Interface    Chassis Id          Port info
>    System Name
>ge-0/0/21.0        -                  00:30:48:c9:54:26  eth1
>    bng-p3-vmm-cloudstack.englab.juniper.net
>ge-0/0/20.0        -                  00:30:48:fd:e4:fc  eth1
>    bng-p3-vmm-vde02-dcbg.englab.juniper.net
>me0.0              -                  78:fe:3d:d7:f4:80  ge-0/0/2.0
>    x2-sw39
>*
>
>
>Here  bng-p3-vmm-cloudstack.englab.juniper.net  and
>bng-p3-vmm-vde02-dcbg.englab.juniper.net  are the KVM hosts connected to
>the switch
>
>
>-Pradeep
>
>
>
>
>On Friday, December 20, 2013 5:54 AM, Chiradeep Vittal
> wrote:
> 
>What does the LLDP output look like?
>
>
>On 12/18/13 11:03 PM, "Pradeep Cloudstack" 
>wrote:
>
>>Hi ,
>>on a KVM host, I have a bridge interface - cloudbr1 to which eth1 has
>>been added.
>>This is for guest Network.
>>
>>
>>When we create a VM on the KVM host, the NetworkGuru plugin gets to know
>>about cloudbr1
>>(via the KVM traffic label). But is there any means to figure out the
>>ports (like eth1) that have been
>>attached to the bridge interface(in this case cloudbr1) on the KVM?
>>
>>The reason I want to know this is that the lldp output on the switch
>>gives information about eth1 (and not the bridge interfaces).
>>
>>
>>-Pradeep

Re: Create VM - find out the NIC on KVM host connected to a Network switch

[Pradeep Cloudstack]

That is fine. But how do we convey this information to the Mgmt Server ?
Without making any enhancements to MgmtSvr/Agent , is it possible to achieve 
this?

-Pradeep





On Saturday, December 21, 2013 4:19 AM, Chiradeep Vittal 
 wrote:
 
On the KVM host you could parse the output of 'brctl show', but that is
awkward to parse.
Or you might be able to iterate through /sys/devices/virtual/net/* and
work backwards from that.


On 12/19/13 10:16 PM, "Pradeep Cloudstack" 
wrote:

>Hi Chiradeep,
>the LLDP output on the switch looks something like
>
>*
>Local Interface    Parent Interface    Chassis Id          Port info
>    System Name
>ge-0/0/21.0        -                   00:30:48:c9:54:26   eth1
>    bng-p3-vmm-cloudstack.englab.juniper.net
>ge-0/0/20.0        -                   00:30:48:fd:e4:fc   eth1
>    bng-p3-vmm-vde02-dcbg.englab.juniper.net
>me0.0              -                   78:fe:3d:d7:f4:80   ge-0/0/2.0
>    x2-sw39
>*
>
>
>Here  bng-p3-vmm-cloudstack.englab.juniper.net  and
>bng-p3-vmm-vde02-dcbg.englab.juniper.net  are the KVM hosts connected to
>the switch
>
>
>-Pradeep
>
>
>
>
>On Friday, December 20, 2013 5:54 AM, Chiradeep Vittal
> wrote:
> 
>What does the LLDP output look like?
>
>
>On 12/18/13 11:03 PM, "Pradeep Cloudstack" 
>wrote:
>
>>Hi ,
>>on a KVM host, I have a bridge interface - cloudbr1 to which eth1 has
>>been added.
>>This is for guest Network.
>>
>>
>>When we create a VM on the KVM host, the NetworkGuru plugin gets to know
>>about cloudbr1
>>(via the KVM traffic label). But is there any means to figure out the
>>ports (like eth1) that have been
>>attached to the bridge interface(in this case cloudbr1) on the KVM?
>>
>>The reason I want to know this is that the lldp output on the switch
>>gives information about eth1 (and not the bridge interfaces).
>>
>>
>>-Pradeep

Re: Create VM - find out the NIC on KVM host connected to a Network switch

[Pradeep Cloudstack]

Hi Chiradeep,
the LLDP output on the switch looks something like

*
Local Interface    Parent Interface    Chassis Id  Port info  
System Name
ge-0/0/21.0    -   00:30:48:c9:54:26   eth1   
bng-p3-vmm-cloudstack.englab.juniper.net
ge-0/0/20.0    -   00:30:48:fd:e4:fc   eth1   
bng-p3-vmm-vde02-dcbg.englab.juniper.net
me0.0  -   78:fe:3d:d7:f4:80   ge-0/0/2.0 
x2-sw39
*


Here  bng-p3-vmm-cloudstack.englab.juniper.net  and 
bng-p3-vmm-vde02-dcbg.englab.juniper.net  are the KVM hosts connected to the 
switch


-Pradeep




On Friday, December 20, 2013 5:54 AM, Chiradeep Vittal 
 wrote:
 
What does the LLDP output look like?


On 12/18/13 11:03 PM, "Pradeep Cloudstack" 
wrote:

>Hi ,
>on a KVM host, I have a bridge interface - cloudbr1 to which eth1 has
>been added.
>This is for guest Network.
>
>
>When we create a VM on the KVM host, the NetworkGuru plugin gets to know
>about cloudbr1
>(via the KVM traffic label). But is there any means to figure out the
>ports (like eth1) that have been
>attached to the bridge interface(in this case cloudbr1) on the KVM?
>
>The reason I want to know this is that the lldp output on the switch
>gives information about eth1 (and not the bridge interfaces).
>
>
>-Pradeep

Create VM - find out the NIC on KVM host connected to a Network switch

[Pradeep Cloudstack]

Hi ,
on a KVM host, I have a bridge interface - cloudbr1 to which eth1 has been 
added.
This is for guest Network.


When we create a VM on the KVM host, the NetworkGuru plugin gets to know about 
cloudbr1
(via the KVM traffic label). But is there any means to figure out the ports 
(like eth1) that have been
attached to the bridge interface(in this case cloudbr1) on the KVM?

The reason I want to know this is that the lldp output on the switch gives 
information about eth1 (and not the bridge interfaces).


-Pradeep

[PROPOSAL] Cloudstack network-element plugin to orchestrate Juniper's switches (for L2 services)

[Pradeep Cloudstack]

Hi,
my name is Pradeep HK and I am from Juniper Networks, Bangalore.

I have prepared a Design Document for the feature mentioned in the subject. It 
is being targetted for 4.4.

Pls review the Design document -
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+network-element+plugin+to+orchestrate+Juniper%27s+switches+%28for+L2+services%29

and send me your comments

-Pradeep

Re: [DISCUSS] Cloudstack network-element plugin(ver 4.2) to orchestrate Juniper's switches

[Pradeep Cloudstack]

Thanks Chiradeep

-Pradeep





On Thursday, December 5, 2013 11:14 PM, Chiradeep Vittal 
 wrote:
 
Hi Pradeep,
Take a look at this: https://cwiki.apache.org/confluence/x/6x-VAQ
Feature freeze for 4.4 is targeted for end of February. So, now would be
the ideal time to propose this feature to the community.
See https://cwiki.apache.org/confluence/x/0h-VAQ for how to go about this.


On 12/5/13 2:03 AM, "Pradeep Cloudstack" 
wrote:

>Hi Chiradeep Vittal,
>can this be considered for 4.4 ?
>
>-Pradeep
>
>
>
>
>On Tuesday, December 3, 2013 12:33 PM, Chiradeep Vittal
> wrote:
> 
>I think this is a great idea. However 4.2 is closed for new features (as
>also 4.3). 
>
>
>
>On 12/2/13 3:23 AM, "Pradeep Cloudstack" 
>wrote:
>
>>Hi,
>>my name is Pradeep HK and I am from Juniper Networks, Bangalore.
>>
>>I am leading an effort to implement Cloudstack(based on 4.2)
>>network-element plugin to orchestrate Juniper's switches.
>>
>>As a first-cut, we are focussing on L2 services and we have written a
>>NetworkGuru. As part of it's implement() method we will:
>>(1)Create the required logical interfaces on the Juniper switches
>>(EX,QFX)
>>(2)Create the required VLANs on the Juniper switches (EX,QFX).
>>(3)Configure VLAN membership on the interfaces
>>
>>
>>Our customers need this plugin in Cloudstack deployments to automatically
>>orchestrate the Juniper switches to create Virtual Networks.
>>Without this plugin, there will be a manual intervention needed to
>>configure the switches (after figuring out the
>>current configuration of the switch).
>>
>>We have a Network Management Platform (called JUNOS SPACE) which is
>>heavily used by customers to orchestrate  Juniper's  networking devices.
>>It also exposes REST-ful APIs for integration with 3rdParty tools.
>>The proposed Juniper's Cloudstack network-element plugin leverages these
>>REST-ful APIs to appropriately orchestrate Juniper's switches to
>>create Virtual Networks
>>
>>In that direction, I need:
>>(1)Your comments/suggestions
>>(2)For existing deployments of Cloudstack, is there a standard means to
>>deploy the Plugin ?
>>
>>-Pradeep

Re: [DISCUSS] Cloudstack network-element plugin(ver 4.2) to orchestrate Juniper's switches

[Pradeep Cloudstack]

Hi Chiradeep Vittal,
can this be considered for 4.4 ?

-Pradeep




On Tuesday, December 3, 2013 12:33 PM, Chiradeep Vittal 
 wrote:
 
I think this is a great idea. However 4.2 is closed for new features (as
also 4.3). 



On 12/2/13 3:23 AM, "Pradeep Cloudstack" 
wrote:

>Hi,
>my name is Pradeep HK and I am from Juniper Networks, Bangalore.
>
>I am leading an effort to implement Cloudstack(based on 4.2)
>network-element plugin to orchestrate Juniper's switches.
>
>As a first-cut, we are focussing on L2 services and we have written a
>NetworkGuru. As part of it's implement() method we will:
>(1)Create the required logical interfaces on the Juniper switches (EX,QFX)
>(2)Create the required VLANs on the Juniper switches (EX,QFX).
>(3)Configure VLAN membership on the interfaces
>
>
>Our customers need this plugin in Cloudstack deployments to automatically
>orchestrate the Juniper switches to create Virtual Networks.
>Without this plugin, there will be a manual intervention needed to
>configure the switches (after figuring out the
>current configuration of the switch).
>
>We have a Network Management Platform (called JUNOS SPACE) which is
>heavily used by customers to orchestrate  Juniper's  networking devices.
>It also exposes REST-ful APIs for integration with 3rdParty tools.
>The proposed Juniper's Cloudstack network-element plugin leverages these
>REST-ful APIs to appropriately orchestrate Juniper's switches to
>create Virtual Networks
>
>In that direction, I need:
>(1)Your comments/suggestions
>(2)For existing deployments of Cloudstack, is there a standard means to
>deploy the Plugin ?
>
>-Pradeep

Re: [DISCUSS] Cloudstack network-element plugin(ver 4.2) to orchestrate Juniper's switches

[Pradeep Cloudstack]

Hi Chiradeep,
is there a way for existing customers of Cloudstack(say running 4.2) to try out 
our plugin?
like say deploying a war file in Tomcat container etc


-Pradeep





On Tuesday, December 3, 2013 12:33 PM, Chiradeep Vittal 
 wrote:
 
I think this is a great idea. However 4.2 is closed for new features (as
also 4.3). 



On 12/2/13 3:23 AM, "Pradeep Cloudstack" 
wrote:

>Hi,
>my name is Pradeep HK and I am from Juniper Networks, Bangalore.
>
>I am leading an effort to implement Cloudstack(based on 4.2)
>network-element plugin to orchestrate Juniper's switches.
>
>As a first-cut, we are focussing on L2 services and we have written a
>NetworkGuru. As part of it's implement() method we will:
>(1)Create the required logical interfaces on the Juniper switches (EX,QFX)
>(2)Create the required VLANs on the Juniper switches (EX,QFX).
>(3)Configure VLAN membership on the interfaces
>
>
>Our customers need this plugin in Cloudstack deployments to automatically
>orchestrate the Juniper switches to create Virtual Networks.
>Without this plugin, there will be a manual intervention needed to
>configure the switches (after figuring out the
>current configuration of the switch).
>
>We have a Network Management Platform (called JUNOS SPACE) which is
>heavily used by customers to orchestrate  Juniper's  networking devices.
>It also exposes REST-ful APIs for integration with 3rdParty tools.
>The proposed Juniper's Cloudstack network-element plugin leverages these
>REST-ful APIs to appropriately orchestrate Juniper's switches to
>create Virtual Networks
>
>In that direction, I need:
>(1)Your comments/suggestions
>(2)For existing deployments of Cloudstack, is there a standard means to
>deploy the Plugin ?
>
>-Pradeep

[DISCUSS] Cloudstack network-element plugin(ver 4.2) to orchestrate Juniper's switches

[Pradeep Cloudstack]

Hi,
my name is Pradeep HK and I am from Juniper Networks, Bangalore.

I am leading an effort to implement Cloudstack(based on 4.2) network-element 
plugin to orchestrate Juniper's switches.

As a first-cut, we are focussing on L2 services and we have written a 
NetworkGuru. As part of it's implement() method we will:
(1)Create the required logical interfaces on the Juniper switches (EX,QFX)
(2)Create the required VLANs on the Juniper switches (EX,QFX). 
(3)Configure VLAN membership on the interfaces


Our customers need this plugin in Cloudstack deployments to automatically 
orchestrate the Juniper switches to create Virtual Networks. 
Without this plugin, there will be a manual intervention needed to configure 
the switches (after figuring out the 
current configuration of the switch). 

We have a Network Management Platform (called JUNOS SPACE) which is heavily 
used by customers to orchestrate  Juniper's  networking devices.
It also exposes REST-ful APIs for integration with 3rdParty tools.
The proposed Juniper's Cloudstack network-element plugin leverages these 
REST-ful APIs to appropriately orchestrate Juniper's switches to
create Virtual Networks

In that direction, I need:
(1)Your comments/suggestions
(2)For existing deployments of Cloudstack, is there a standard means to deploy 
the Plugin ?

-Pradeep