Re: Review Request 14023: NetworkManager Exception Fix Due to call to getDhcpServiceProvider()

[Murali Reddy]

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


Could you please rebase to master and submit the patch, fix need to go into 
NetworkOrchestrator.

- Murali Reddy


On Sept. 6, 2013, 10:26 p.m., Soheil Eizadi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14023/
> ---
> 
> (Updated Sept. 6, 2013, 10:26 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> I ran the master branch with my NetworkElement integrated which provides DHCP 
> service. In my use case I was able to create a VM but when I deleted it there 
> was an exception in the NetworkManager when it called:
> 
> isDhcpAccrossMultipleSubnetsSupported() >> getDhcpServiceProvider()
> 
> 
> My DHCP Provider is a NetworkElement but does not implement the 
> DhcpServiceProvider interface.
> 
> 
>public DhcpServiceProvider getDhcpServiceProvider(Network network) {
> 
> String DhcpProvider = 
> _ntwkSrvcDao.getProviderForServiceInNetwork(network.getId(), Service.Dhcp);
> 
> 
> if (DhcpProvider == null) {
> 
> s_logger.debug("Network " + network + " doesn't support service " 
> + Service.Dhcp.getName());
> 
> return null;
> 
> }
> 
> 
> return 
> (DhcpServiceProvider)_networkModel.getElementImplementingProvider(DhcpProvider);
> 
> 
> }
> 
> 
> There is a check in the NetworkManager in the Prepare stage but a similar 
> check is missing in Release stage.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkManagerImpl.java ae27554 
> 
> Diff: https://reviews.apache.org/r/14023/diff/
> 
> 
> Testing
> ---
> 
> I verified in my environment where due to VM expunge failing to 
> NetworkManager exception the system would retry on a timer. After the fix the 
> VM was removed from the system after the first retry.
> 
> 
> Thanks,
> 
> Soheil Eizadi
> 
>

Re: [DISCUSS] Leaky abstractions [was review requests 13238, 13896, 14320]

[murali reddy]

On Thu, Oct 3, 2013 at 4:18 PM, Daan Hoogland wrote:

> Chiradeep,
>
> I have been thinking about your concern and there is something bothering me
> about it. The issue CLOUDSTACK-4328 of which
> https://reviews.apache.org/r/14320/ is an implementation. This issue has
> been brought up by the engineers at Schuberg Philis. These are cloud
> operators and domain admins. So these are the people that need to be
> bothered by this tuning and they are certainly haproxy and xen experts to
> an extend. For them not being able to use connection caching was a bug. And
> the proposed solution still seems reasonable to me. It is exposing the
> abstract feature only to those instantiating a vpc, isn't it? This last
> question probably touches on the reason you are addressing my submission
> together with the ones from Nicolas  I see only people instantiating a vpc
> having to be bothered by which netoffering to use (with respect to
> httpClose functionality) If this is not the case how should I isolate this
> concern from other , more mondain users?
>
> btw I did not create an FS page as the issue was created as a jira ticket.
> I am willing to do that in hind sight but want to have a path to follow
> first.
>
> regards,
> Daan
>
> On Tue, Oct 1, 2013 at 11:06 PM, Chiradeep Vittal <
> chiradeep.vit...@citrix.com> wrote:
> >
> > We have a couple of people trying to expose the advanced capabilities of
> the underlying physical resources to the end-user. In the case of Nicolas
> FOATA, he is trying to expose some of the advanced functions of
> XenServer/XCP, and in the case of Daan, he is trying to expose some feature
> of HAProxy.
> >
> > Users are ideally abstracted from these details and shouldn't have to
> wonder which offering to choose [because they are not Xen/HAProxy experts].
> > After all one of the goals of CS is to hide these messy details and let
> users focus on their apps.
> >
> > Is there a possibility of a generic way of leaking abstractions for
> sufficiently advanced users?
> >
>

Generally as a principle core API's abstract and expose functionality that
is commonly available across the hypervisors and network service providers
etc.. I believe we should continue to enforce it.

But we do have a pattern of API's configure* (configurevirtualrouter,
configurenetscaler etc) where a hypervisor/network element plug-in can let
admin to configure params specific to plug-in. Perhaps we can use this
API's fine tune a plugin for advanced configurations. For e.g both HaProxy
max connections, httpModeEnabled can be parameters that can be configured
with configureVirtualRouter api.

Daan,

does this approach works for you?

-Murali


> > https://reviews.apache.org/r/13238/
> > https://reviews.apache.org/r/14320/
> > https://reviews.apache.org/r/13896/
> >
> > BTW, I really prefer that these changes are discussed by putting up an FS
> on the wiki rather than submitting patch requests.
> > If it touches more than a few files, it is probably worth discussing with
> a [DISCUSS] tag line.
> > Also, it requires tests.
> >
> >
> >
>

Re: [DISCUSS] Leaky abstractions [was review requests 13238, 13896, 14320]

[Murali Reddy]

On 04/10/13 12:32 AM, "Chip Childers"  wrote:

>> On Oct 3, 2013, at 3:01 PM, Chiradeep Vittal
>> wrote:
>>
>> I was thinking along the same lines that a offering could have a generic
>> key/value map (where the value could be a string/json string/whatever).
>> CloudStack core wouldn't have any idea about the semantics of the keys
>>or
>> values, but the specific hypervisor/provider might decide to interpret
>>it.
>
>+1 - a model for extensions like that makes perfect sense.

We already have api's (add/list/removeResourceDetails) in 4.2 [1] to add
key-value metadata to first class objects of CloudStack. At present it
does not have semantic meaning to neither core nor plug-ins, but should
not be hard to extend so that plug-ins can access meta-data and interpret
it.

[1] http://s.apache.org/ReK

>
>>
>>
>>> On 10/3/13 11:15 AM, "Darren Shepherd" 
>>>wrote:
>>>
>>> We are always going to run into the issue where they're implementation
>>> specific features that can't be represented in a generic way in the
>>> API.  First class attributes in the API need to essentially be the
>>> lowest common denominator.  ACS already has this pattern of *_details
>>> tables.  I honestly don't know completely how they are used, but I
>>> would hope that pattern could be used to address these types of
>>> issues.  By allowing the admin to add arbitrary key/value pairs to the
>>> various offerings/entities we can use that to tap into provider
>>> specific or advanced configuration.  For the http close proposal you
>>> could just add haproxy.httpClose=true on the network offering and the
>>> haproxy impl can respect that and use it.  So implementations can
>>> document what additional key/value parameters they support to access
>>> advanced features.
>>>
>>> Review 13896 adds an otherOptions field to the service offering.
>>> Conceptually that is fine in my mind, but I just don't understand why
>>> the *_details tables can't be used instead.  Just like XenServer has
>>> other_config on all types, I'd like it if ACS had a similar thing
>>> (which I kinda, sorta think it does?).  So we should be able to
>>> arbitrary data onto any type.  Can somebody comment on how this idea
>>> may relate with the existing implementation of "details" and "tags" in
>>> ACS?
>>>
>>> Darren
>>>
>>> On Thu, Oct 3, 2013 at 10:21 AM, Daan Hoogland
>>>
>>> wrote:
>>>> Murali,
>>>>
>>>> What our admins need is the ability to instantiate an abstract thing
>>>> called
>>>> a virtual redundant high available router. They need be able to tune
>>>>it
>>>> with all sorts of features is such a way that other routers redundant
>>>>or
>>>> not and high availible or not, may but do not have to have the same
>>>> tuning
>>>> parameters. This 'feature' of httpClose is just one of the many things
>>>> they
>>>> need to be able to tune. Others include a more fine grained control
>>>>over
>>>> the iptables/firewall rules and monitoring of the
>>>>functionality/daemons
>>>> running on the machines. I am not biased as to the way how to
>>>> do/implement
>>>> this control. The networkoffering seemed like the way to do it.
>>>>
>>>> Having said that I didn't think that httpClose would be considered
>>>> haproxy
>>>> specific. It seems worrying that someone could device a proxy or a
>>>> loadbalancer that does not support either one of the features of
>>>> maximizing - or pooling connections. I'm not into that market recently
>>>> so I
>>>> might be mistaking. This maybe besides the point but it discomforts me
>>>> somewhat.
>>>>
>>>> regards,
>>>> Daan
>>>>
>>>>
>>>> On Thu, Oct 3, 2013 at 2:22 PM, murali reddy
>>>> wrote:
>>>>
>>>>> On Thu, Oct 3, 2013 at 4:18 PM, Daan Hoogland
>>>>>>>>>> wrote:
>>>>>
>>>>>> Chiradeep,
>>>>>>
>>>>>> I have been thinking about your concern and there is something
>>>>> bothering
>>>>> me
>>>>>> about it. The issue CLOUDSTACK-4328 of which
>>>>>> https://reviews.apache.org/r/14320/ is an imp

Re: ACS 4.2 - Error when trying to declare a LB rule in a vpc to a tier network with lb offering

[Murali Reddy]

On 08/10/13 7:41 PM, "benoit lair"  wrote:

>Hello!
>
>I don't understand wht is going wrong :
>
>When i'm looking into the official docs, i see that vpc is still declared
>to be able to do lb only on one tier ??
>
>However, https://issues.apache.org/jira/browse/CLOUDSTACK-2367 says that
>this feature is implemented.

Both external and internal LB are supported. Please see [1]. Both both
functionality are mutually exclusive with in a tier. From the exception it
appears that you are trying to do external LB on tier created with
'DefaultIsolatedNetworkOfferingForVpcNetworksWithInternalLB' offering
which does not support it. Try creating a tier with a network offering
with lb type as 'public lb'

[1] 
https://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Insta
llation_Guide/configure-vpc.html#add-loadbalancer-rule-vpc

>
>I have already configured several tiers in a vpc with internal lb service
>for each, i deployed several vms into 2 differents tiers.
>
>But when i try to create a lb rule choosing two vm in a tier, i got the
>error message i noticed two messages ago.
>
>If somebody has an idea, i would really appreciate.
>
>Thanks.
>
>Benoit.
>
>
>2013/10/8 benoit lair 
>
>> Hello!
>>
>> Any ideas for this problem ?
>>
>> Thanks for your help.
>>
>> Regards,
>>
>> Benoit.
>>
>>
>> 2013/10/7 benoit lair 
>>
>>> Hi,
>>>
>>> I'm working with a CS 4.2, Xenserver 6.2 in a centos 6.3
>>>
>>> Deployed a VPC, multiples tiers, each with a Network offering with LB
>>> activated.
>>>
>>> When i navigate on the vpc summary page, i click on the button "Public
>>>ip
>>> adresses" on the Vpc virtual router item,
>>>
>>> I click on acquire new ip, this one is 10.14.6.5, i click on this one
>>>and
>>> go to configuration tab. I click on load balacing, try to create a lb
>>>rule
>>> very simple :
>>>
>>> just a name, port public 80, private port 80, algorithm least
>>> connections, no stickiness, no health check, no autoscale, just select
>>>2
>>> vms already deployed and running :
>>>
>>> I try to create my lb rule, i got this error message in the UI :
>>>
>>> Failed to create load balancer rule: lb_rule_mano_frontal1
>>>
>>>
>>> When i look into my mgmt server log :
>>>
>>> 2013-10-07 11:54:46,591 DEBUG [cloud.network.NetworkManagerImpl]
>>> (catalina-exec-21:null) Associating ip Ip[10.14.6.5-1] to network
>>> Ntwk[204|Guest|13]
>>> 2013-10-07 11:54:46,598 DEBUG [cloud.network.NetworkManagerImpl]
>>> (catalina-exec-21:null) Successfully associated ip address 10.14.6.5 to
>>> network Ntwk[204|Guest|13]
>>> 2013-10-07 11:54:46,604 WARN
>>>[network.lb.LoadBalancingRulesManagerImpl]
>>> (catalina-exec-21:null) Failed to create load balancer due to
>>> com.cloud.exception.InvalidParameterValueException: Scheme Public is
>>>not
>>> supported by the network offering [Network Offering
>>> [13-Guest-DefaultIsolatedNetworkOfferingForVpcNetworksWithInternalLB]
>>> at
>>> 
>>>com.cloud.network.lb.LoadBalancingRulesManagerImpl.isLbServiceSupportedI
>>>nNetwork(LoadBalancingRulesManagerImpl.java:2136)
>>> at
>>> 
>>>com.cloud.network.lb.LoadBalancingRulesManagerImpl.createPublicLoadBalan
>>>cer(LoadBalancingRulesManagerImpl.java:1432)
>>> at
>>> 
>>>com.cloud.utils.component.ComponentInstantiationPostProcessor$Intercepto
>>>rDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>> at
>>> 
>>>com.cloud.network.lb.LoadBalancingRulesManagerImpl.createPublicLoadBalan
>>>cerRule(LoadBalancingRulesManagerImpl.java:1360)
>>> at
>>> 
>>>com.cloud.utils.component.ComponentInstantiationPostProcessor$Intercepto
>>>rDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>> at
>>> 
>>>org.apache.cloudstack.api.command.user.loadbalancer.CreateLoadBalancerRu
>>>leCmd.create(CreateLoadBalancerRuleCmd.java:282)
>>> at
>>> com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:104)
>>> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:460)
>>> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372)
>>> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305)
>>> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>>> at
>>> 
>>>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>>tionFilterChain.java:290)
>>> at
>>> 
>>>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>>erChain.java:206)
>>> at
>>> 
>>>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
>>>e.java:233)
>>> at
>>> 
>>>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
>>>e.java:191)
>>> at
>>> 
>>>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
>>>:127)
>>> at
>>> 
>>>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>>>:102)
>>> at
>>> 
>>>org.apache.catalina.valves.Acce

Re: what's the reason for the placeholder nic in VPC/VR?

[Murali Reddy]

On 09/10/13 11:33 AM, "Darren Shepherd" 
wrote:

>Why is a placeholder nic created before the VRs for the VPC are created?
>
>Darren
>

Generally place holder nic is used in cases where cloudstack uses a subnet
IP from the guest subnet, but ip is not used for any VM nic's. In most of
the external network devices, needs a subnet IP from the guest network
CIDR, cloudstack creates a place holder nic and allocates a subnet ip.

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Murali Reddy]

Thanks Syed for the FS.

Couple of comments:

- any reason why you choose assignTo/RemoveFrom load balancer rule API's
to assign/remove certificate to LB rules? These api's are basically for
controlling VM membership with a load balancer rule. Can
create/updateLoadBalancerRule api's b used for registering and
de-registering certificate with load balancer rule?

- to me SSL termination is value added service from providers perspective,
its better we expose service differentiation in the network offering (e.g
dedicated load balancer capability of LB service in the network offering).
So only if network offering permits, SSL termination can be used.

- does adding SSL termination support to load balancer affect/complement
current session persistence, health monitoring, auto scale functionality
anyway? I see session persistence based on SSL session id's please see if
this can supported.

- as commented by other, fail fast at service layer on invalid certificate.

- on the requirement #4, don't infer protocol based on the public/private
ports and impose restrictions. Current createLoadBalancer API does not
take protocol parameter so its inferred at device layer. NetScaler seems
to support SSL with other TCP ports as well.

One general implementation note, network rules can be reprogrammed. So
operations to configure SSL cert, binding cert to virtual server etc need
to be idempotent at NetScaler resource.

[1] 
http://support.citrix.com/proddocs/topic/netscaler-ssl-93/ns-ssl-offloading
-other-tcp-protocols-tsk.html

On 08/10/13 11:44 PM, "Syed Ahmed"  wrote:

>Hi,
>
>I have been working on adding SSL offload functionality to cloudstack
>and make it work for Netscaler. I have an initial design documented at
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Supp
>ort 
>and I would really love your feedback. The bug for this is
>https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>
>Thanks,
>-Syed
>
>
>

Re: Contrail plugin

[Murali Reddy]

On 09/10/13 6:10 AM, "Pedro Roque Marques" 
wrote:

>Darren,
>Using ActionEvents is not desirable for the plugin either... today
>CloudStack lacks the ability for a component/plugin to associate itself
>to the life-cycle of an object. It would be ideal if there was a generic
>way to accomplish that...
>The contrail plugin wants to know about project creation and deletion.
>Projects need to be reflected in the contrail-api server; the project
>delete notification is necessary to understand that the project is not
>longer used.
>
>When it comes to network objects it would also be nice if there could a
>for a component/plugin to associate itself with network creation /
>implementation... Currently there are calls from the NetworkManager to
>components such as firewall/LB/etc which should be optional.
>
>Ideally, i would like to have a common notification mechanism for a
>cloudstack object (e.g. project, network, nic). This could optionally
>allow a plugin to "veto" an operation and/or just get notified that it
>occurred.

For 'veto' to operations, yes you are right that CloudStack core does not
give hooks into workflow for plug-ins to veto. But there are defined
abstraction (Guru, Planner, Investigator etc.) through which plug-ins can
hook into orchestration. Also there is a publisher/subscriber modelled
EventBus that was added in 4.1 by which CloudStack components can get the
entity life cycle and state changes. I see that contrail plug-in
implements an Interceptor for achieving this, but I will leave a comment
in the review if 'EventBus' can leveraged.

Thanks,
Murali

>
>thanks,
>  Pedro.
>
>On Oct 8, 2013, at 10:25 AM, Darren Shepherd wrote:
>
>> I'll take some time and review this code too.  I already know there's
>> going to be a conflict with the stuff I did in the spring
>> modularization branch.  Moving to full spring we have gotten rid of
>> the custom ACS AOP for the mgmt server.  This code relies on that
>> framework so it will have to move to being a standard
>> org.aopalliance.intercept.MethodInteceptor.  I don't particularly care
>> for the fact that functionally it being keyed off of ActionEvents (or
>> AOP in general).  I'll need to review the code further to provide more
>> useful feedback, but just giving the heads up that the AOP stuff will
>> have to change a bit.
>> 
>> Darren
>
>

Re: Review Request 14549: Rename net.juniper.contrail to org.apache.cloudstack.network.contrail

[Murali Reddy]

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


- Is there a reason why no new isolation type was not added for 'contrail 
controller'. For other overlay technologies (STT, GRE, VXLAN) that CloudStack 
support there is an isolation type and corresponding Guru that handles 
isolation type. 

- There is a 'EventBus' on to which all events generated by CloudStack gets 
published. Right approach would be to plug-in to subscribe to interested events 
from event bus. But the current implementation of EventBus expects external 
AMQP server, so it may not be ideal. EventInterceptor approach implemented in 
the plug-in works fine to get the notification. But enabling it by default in 
ApplicationContext does not seem right thing to do. 

- If you can add some more details in to the FS on deployment model it will 
give more perspective to reviewers

+ is the VRouter mentioned in the FS is a appliance provisioned by 
CloudStack for each guest network by servicemanager? Or its a logical router on 
the dataplane that does the forwarding?
+ is BGP/MPLS required on the IP fabric and the Hypervisors


- Murali Reddy


On Oct. 8, 2013, 11:58 p.m., Pedro Marques wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14549/
> ---
> 
> (Updated Oct. 8, 2013, 11:58 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Rename net.juniper.contrail to org.apache.cloudstack.network.contrail.
> 
> 
> Diffs
> -
> 
>   client/tomcatconf/applicationContext.xml.in 0ab2515 
>   client/tomcatconf/componentContext.xml.in 157ad5a 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/api/command/CreateServiceInstanceCmd.java
>  92f5eeb 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/api/response/ServiceInstanceResponse.java
>  1b7a7d8 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailElement.java
>  885a60f 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailElementImpl.java
>  3a38020 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailGuru.java
>  c655b0b 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailManager.java
>  5195793 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ContrailManagerImpl.java
>  8a3ca1b 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/DBSyncGeneric.java
>  d169b37 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/EventUtils.java
>  acd1bed 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ManagementNetworkGuru.java
>  bad2502 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ModelDatabase.java
>  f9e7c24 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServerDBSync.java
>  4c8c2e9 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServerDBSyncImpl.java
>  06daf12 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServerEventHandler.java
>  6f0ecf2 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServerEventHandlerImpl.java
>  aa4e9d5 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServiceManager.java
>  f3884fb 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServiceManagerImpl.java
>  b90792c 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/management/ServiceVirtualMachine.java
>  9c8b61d 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/FloatingIpModel.java
>  ca90666 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/FloatingIpPoolModel.java
>  8e238fd 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/InstanceIpModel.java
>  ff08560 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/ModelController.java
>  7abb40a 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/model/ModelObject.java
>  7cd420c 
> 

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Murali Reddy]

On 09/10/13 8:08 PM, "Syed Ahmed"  wrote:

>Thanks Murali for your response.
>
>> - any reason why you choose assignTo/RemoveFrom load balancer rule API's
>
>I thought this made more sense than create/updateLoadbalancerRule as
>we would have to call update to delete a cert which I find somewhat
>confusing. Also this is semantically similar to attaching instances as
>in you have a separate entity which is being bound to different LBs.

We will be just overloading the assignTo/RemoveFrom load balancer rule
API's for associate/dis-associte certificate with load balancer rule. IMO,
its better we introduce new api's say
registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than
force fit existing API's for associate/dis-associate certificates.

>
>> - to me SSL termination is value added service from providers
>>perspective,
>> So only if network offering permits, SSL termination can be used.
>
>Got it. This seems the logical way. Good point.

On second thought may be an CloudStack usage event on assigning
certificate seems good enough to me.

>
>Would it be a good Idea to add protocol to the createLoadBalancer API.
>I think this makes sense in the long run as currently I cannot create
>a HTTP loadbalncer for port 8080 from cloudstack.

Yes, its good we introduce protocol in the API, and make it optional
parameter. Currently CloudStack marks protocol as TCP by default and load
balancer implementation layer corresponding to HAProxy, F5, NetScaler we
are inferring protocol from the ports. So on upgrade just ensure we don't
break backward compatibility of the existing load balancer rules.

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Murali Reddy]

On 11/10/13 9:31 PM, "Syed Ahmed"  wrote:

>Thanks for your valuable feedback Murali. Here are my comments.
>
>> IMO,
>> its better we introduce new api's say
>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than
>> force fit existing API's for associate/dis-associate certificates.
>
>Personally, I was going to do it this way. But I am not sure how good
>of an idea it is to add a new api just for this feature as I can see
>assignToLoadbalancer is semantically similar. But if everyone agrees I
>have no problem with it.

CloudStack already has distinct API's for each of the LB sub-functionality
(health check, stickiness etc) [1]. We are not adding any redundant API,
so resulting API are much cleaner just managing SSL termination for a LB
rule. 

>
>> On second thought may be an CloudStack usage event on assigning
>> certificate seems good enough to me.
>
>So what I got from your earlier post was that when adding a  network
>offering the provider can choose to enable SSL Termination or not as it
>is a value added service. I was thinking of adding "SSL termination"
>under supportedservices for the  createNetworkOffering API call. And
>when someone calls the API to assign a cert to LB we can check if this
>network offering has SSL termination enabled. Does this make sense?

So there is notion of network service and network service capability [2].
I would attribute 'SSL termination' as capability of LB service.
createNetworkOffering API take a capability list. It does make sense to
check if the network offering has SSL termination enabled when API to
assign a cert to LB is called. Also note that, 'Network Elements' declare
their capabilities for the supported services. So it can verified that
service provider for LB actually supports 'SSL termination' capability
while creating network offering.


>
>Also when you say usage event, what does this imply? I am sorry I am
>not familiar with that term. Can you please elaborate.

Its an event generated and persisted in the DB for every resource
consumption and release. These events are used for billing etc. Please
check publishUsageEvent calls in the code.

[1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
[2] api/src/com/cloud/network/Network.java

Re: Review Request 14549: Rename net.juniper.contrail to org.apache.cloudstack.network.contrail

[Murali Reddy]

> On Oct. 9, 2013, 2:49 p.m., Murali Reddy wrote:
> > - Is there a reason why no new isolation type was not added for 'contrail 
> > controller'. For other overlay technologies (STT, GRE, VXLAN) that 
> > CloudStack support there is an isolation type and corresponding Guru that 
> > handles isolation type. 
> > 
> > - There is a 'EventBus' on to which all events generated by CloudStack gets 
> > published. Right approach would be to plug-in to subscribe to interested 
> > events from event bus. But the current implementation of EventBus expects 
> > external AMQP server, so it may not be ideal. EventInterceptor approach 
> > implemented in the plug-in works fine to get the notification. But enabling 
> > it by default in ApplicationContext does not seem right thing to do. 
> > 
> > - If you can add some more details in to the FS on deployment model it will 
> > give more perspective to reviewers
> > 
> > + is the VRouter mentioned in the FS is a appliance provisioned by 
> > CloudStack for each guest network by servicemanager? Or its a logical 
> > router on the dataplane that does the forwarding?
> > + is BGP/MPLS required on the IP fabric and the Hypervisors
> >
> 
> Pedro Marques wrote:
> Murali,
> We didn't add a new isolation type to avoid changing the CloudStack code. 
> The current define describes the encapsulation technology. Contrail can use 
> several encapsulation technologies: MPLS/GRE, MPLS/UDP, MPLS over VXLAN 
> header. I can add one if you find it helpful... from a technology perspective 
> contrail focus on the control plane solution rather than the encapsulation.
> 
> The event bus doesn't look like an attractive approach. If the 
> ActionEvent listeners will cause a problem we can periodically poll from the 
> plugin.
> 
> The "VRouter" is a linux kernel module running on each Host. BGP/MPLS is 
> a control plane technology. The fabric is required to be able to transport IP 
> packets between Hosts... No other assumption is made; no need for VLANs or 
> MPLS on the fabric.
>

Pedro,

Thanks for clarification. Now I understand that Contrial being control plane 
solution and its ability support multiple encapsulation technologies. Actually 
my earlier comment was not so much about isolation method (CloudStack notion of 
overlay/encapsulation technologies). Currently there is no prescriptive way for 
CloudStack networking to know which NetworkGuru should be handling the network 
design, so it just loops through all network guru to implement & design the 
network. Unfortunately, its network guru to know if it should handle the 
design/implement call etc for a network. For e.g. VxlanGuestNetworkGuru thinks 
its authoritative to handle the isolation method 'VXLAN'. If ContrailGuru 
thinks it can handle VXLAN then there is conflict if both the plug-ins are 
enabled by default in the componentContext. It should not be plug-in developers 
problem, but i want to suggest to add a safe-guard. Either add new isolation 
method (like MIDO for e.g for Midokura) and let Contrail Guru and Ele
 ment to handle only if isolation method is for Contrail.

I agree that event bus approach is not attractive with current RabbitMq 
implementation. What my intention was new interceptor 
(contrailEventInterceptor) be enabled only if some one wants to use Contrail 
plug-in. If Contrial plug-in is not used then interceptor is just adding 
additional overhead. You can make this step (of configuring interceptor in 
applicationContext as setup step).


- Murali


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


On Oct. 8, 2013, 11:58 p.m., Pedro Marques wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14549/
> ---
> 
> (Updated Oct. 8, 2013, 11:58 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Rename net.juniper.contrail to org.apache.cloudstack.network.contrail.
> 
> 
> Diffs
> -
> 
>   client/tomcatconf/applicationContext.xml.in 0ab2515 
>   client/tomcatconf/componentContext.xml.in 157ad5a 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/api/command/CreateServiceInstanceCmd.java
>  92f5eeb 
>   
> plugins/network-elements/juniper-contrail/src/net/juniper/contrail/api/response/ServiceInstanceResponse.java
>  1b7a7d

Re: Review Request 14549: Rename net.juniper.contrail to org.apache.cloudstack.network.contrail

[Murali Reddy]

> On Oct. 9, 2013, 2:49 p.m., Murali Reddy wrote:
> > - Is there a reason why no new isolation type was not added for 'contrail 
> > controller'. For other overlay technologies (STT, GRE, VXLAN) that 
> > CloudStack support there is an isolation type and corresponding Guru that 
> > handles isolation type. 
> > 
> > - There is a 'EventBus' on to which all events generated by CloudStack gets 
> > published. Right approach would be to plug-in to subscribe to interested 
> > events from event bus. But the current implementation of EventBus expects 
> > external AMQP server, so it may not be ideal. EventInterceptor approach 
> > implemented in the plug-in works fine to get the notification. But enabling 
> > it by default in ApplicationContext does not seem right thing to do. 
> > 
> > - If you can add some more details in to the FS on deployment model it will 
> > give more perspective to reviewers
> > 
> > + is the VRouter mentioned in the FS is a appliance provisioned by 
> > CloudStack for each guest network by servicemanager? Or its a logical 
> > router on the dataplane that does the forwarding?
> > + is BGP/MPLS required on the IP fabric and the Hypervisors
> >
> 
> Pedro Marques wrote:
> Murali,
> We didn't add a new isolation type to avoid changing the CloudStack code. 
> The current define describes the encapsulation technology. Contrail can use 
> several encapsulation technologies: MPLS/GRE, MPLS/UDP, MPLS over VXLAN 
> header. I can add one if you find it helpful... from a technology perspective 
> contrail focus on the control plane solution rather than the encapsulation.
> 
> The event bus doesn't look like an attractive approach. If the 
> ActionEvent listeners will cause a problem we can periodically poll from the 
> plugin.
> 
> The "VRouter" is a linux kernel module running on each Host. BGP/MPLS is 
> a control plane technology. The fabric is required to be able to transport IP 
> packets between Hosts... No other assumption is made; no need for VLANs or 
> MPLS on the fabric.
>
> 
> Murali Reddy wrote:
> Pedro,
> 
> Thanks for clarification. Now I understand that Contrial being control 
> plane solution and its ability support multiple encapsulation technologies. 
> Actually my earlier comment was not so much about isolation method 
> (CloudStack notion of overlay/encapsulation technologies). Currently there is 
> no prescriptive way for CloudStack networking to know which NetworkGuru 
> should be handling the network design, so it just loops through all network 
> guru to implement & design the network. Unfortunately, its network guru to 
> know if it should handle the design/implement call etc for a network. For 
> e.g. VxlanGuestNetworkGuru thinks its authoritative to handle the isolation 
> method 'VXLAN'. If ContrailGuru thinks it can handle VXLAN then there is 
> conflict if both the plug-ins are enabled by default in the componentContext. 
> It should not be plug-in developers problem, but i want to suggest to add a 
> safe-guard. Either add new isolation method (like MIDO for e.g for Midokura) 
> and let Contrail Guru a
 nd Element to handle only if isolation method is for Contrail.
> 
> I agree that event bus approach is not attractive with current RabbitMq 
> implementation. What my intention was new interceptor 
> (contrailEventInterceptor) be enabled only if some one wants to use Contrail 
> plug-in. If Contrial plug-in is not used then interceptor is just adding 
> additional overhead. You can make this step (of configuring interceptor in 
> applicationContext as setup step).
>
> 
> Pedro Marques wrote:
> Murali,
> My understanding is that there are two mechanisms in play when it comes 
> to identifying the Guru: the encapsulation and whether an offering is enabled 
> on the physical network attached to the zone. The contrail plugin looks at 
> the later in order to allow the user to have multiple zones with different 
> network offerings.
> 
> I agree that the contrail event interceptor should be enabled only if you 
> want to use the plugin. I'll revert the applicationContext.xml.in change.
> Is it possible for you to accept this diff into the contrail branch ?
> My understanding from Chip is that what we where trying to do is to 
> incrementally get the branch to a stage where it can be merged... it would be 
> easier to do that as a set of commits into the branch.

Your understanding is right. Sorry if i have missed, but i did not see any 
check to see if 'Connectivity' service provider in the network offering is 
'Provider.J

Re: Review Request 14549: Rename net.juniper.contrail to org.apache.cloudstack.network.contrail

[Murali Reddy]

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


patch does not apply cleanly yet. Can you please ensure you are able to apply 
the patch on to master branch and there are no tabs and trailing white spaces.

- Murali Reddy


On Oct. 16, 2013, 6:51 p.m., Pedro Marques wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14549/
> ---
> 
> (Updated Oct. 16, 2013, 6:51 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Rename net.juniper.contrail to org.apache.cloudstack.network.contrail.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/Network.java 49f380b 
>   client/pom.xml fd1f13a 
>   client/tomcatconf/commands.properties.in 58c770d 
>   client/tomcatconf/componentContext.xml.in df5b002 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  92fbab2 
>   plugins/network-elements/juniper-contrail/pom.xml PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/api/command/CreateServiceInstanceCmd.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/api/response/ServiceInstanceResponse.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailElement.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailElementImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailGuru.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailManager.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailManagerImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/DBSyncGeneric.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/EventUtils.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ManagementNetworkGuru.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ModelDatabase.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerDBSync.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerDBSyncImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerEventHandler.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerEventHandlerImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceManager.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceManagerImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceVirtualMachine.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/FloatingIpModel.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/FloatingIpPoolModel.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/InstanceIpModel.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelController.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelObject.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelObjectBase.java
>  PRE-CREATIO

OVS integration broken in 4.2 & master

[Murali Reddy]

OVS integration for GRE overlay tunnels is currently broken in both master and 
4.2. Till 4.1, Network Manager will loop through all the network elements for 
NIC prepare and release so, OVS network element had chance to participate in 
the NIC prepare/release operations. This behaviour in network orchestrator is 
changed to loop through only network elements that are service providers for 
the network which is right way to do, but OVS network element is not called due 
to this. I am planning to fix it by making Ovs network element as service 
provider for 'Connectivity' service. This is in consistence with design of 
other SDN controllers integrated in CS. So, to use GRE isolation, additional 
step is required to create a network offering with 'Ovs' as connectivity 
service provider. Any concerns with this approach?

Re: [MERGE] network-guru-orchestration into master

[Murali Reddy]

On 29/10/13 10:12 PM, "Hugo Trippaers"  wrote:

>Hey guys,
>
>This is something i had on my wish list for some time. The current way
>network gurus are handled is that each guru is asked to design a network
>and will decide by itself to either do it or don¹t. Most gurus have sane
>checks on which types of networks it can handle, but we have seen issues
>there in the past.
>
>With these changes the network orchestrator will check the capabilities
>of a guru and based on that ask one or more gurus to design the network.
>With this the power is where is should new, the network orchestrator.
>
>This also means that new networking plugins with gurus will have an
>easier integration, just list the capabilities. It will also save some
>database calls (once i clean out all canHandle functions) as gurus will
>have to lookup less to decide if they should to their job.
>
>What do you guys think?

Nice. Looks like getting the supported guru's by traffic type, network
type, guest type, isolation method is already covering all the guru's with
out ambiguity.  +1 for addressing the problem and merge.


>
>Current branch is tested with devcloud in a manual test, so there is more
>work to do there. I wanted to get some opinions while performing more
>tests.
>
>Cheers,
>
>Hugo

Re: Review Request 14976: [SSL Termination support] Part2 : Assign certificates to LBs

[Murali Reddy]

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



api/src/com/cloud/event/EventTypes.java
<https://reviews.apache.org/r/14976/#comment54828>

please add events for certificate upload and delete events as well



api/src/com/cloud/network/lb/CertService.java
<https://reviews.apache.org/r/14976/#comment54829>

Should the 'validate' method be internal to certificate service?



api/src/com/cloud/network/lb/LoadBalancingRule.java
<https://reviews.apache.org/r/14976/#comment54830>

can you please add new constructors which takes ssl cert and protocol. If 
we extend same constructor then its resulting unnecessary changes in internal 
lb, elastic lb code as well.



server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
<https://reviews.apache.org/r/14976/#comment54818>

need a better error message. its actually mismatch in owners of lb rule, 
certificate and caller



server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
<https://reviews.apache.org/r/14976/#comment54833>

remove the comments if not required


- i dont see certificate details in the load balancer response obtained from 
listLoadBalancerRules.Does it make sense to give the certificate details if 
there is a cert assigined to load balancer rule?

- i dont see code to add a network offering with 'SslTermination'capability. 
Also list network offering, should show if LB service with SSL termination is 
supported by the offering. 

- Please add Apache license header to all files.

- Murali Reddy


On Oct. 30, 2013, 8:34 p.m., Syed Ahmed wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14976/
> ---
> 
> (Updated Oct. 30, 2013, 8:34 p.m.)
> 
> 
> Review request for cloudstack, Darren Shepherd, Murali Reddy, and Sheng Yang.
> 
> 
> Bugs: CLOUDSTACK-4821
> https://issues.apache.org/jira/browse/CLOUDSTACK-4821
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This is the second patch for SSL termination support. This patch impletements 
> the assginement of certificate to loadbalancers. Support for netscaler is 
> also added. Due to the version of netscaler API in CS, I could not add 
> support for certificate chain. This should not be a big change however. We 
> can discuss this.
> 
> 
> NOTE: Because I cannot diff with my local branch, this patch also includes 
> the first patch which includes certificate management logic ... sorry 
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/LoadBalancerTO.java df2f8a8 
>   api/src/com/cloud/event/EventTypes.java a762606 
>   api/src/com/cloud/network/Network.java 49f380b 
>   api/src/com/cloud/network/lb/CertService.java PRE-CREATION 
>   api/src/com/cloud/network/lb/LoadBalancingRule.java 4b37782 
>   api/src/com/cloud/network/lb/LoadBalancingRulesService.java 59d5c8d 
>   api/src/com/cloud/network/lb/SslCert.java PRE-CREATION 
>   api/src/org/apache/cloudstack/api/ApiConstants.java c75e6a0 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCertToLoadBalancerCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/CreateLoadBalancerRuleCmd.java
>  a368436 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/DeleteSslCertCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListSslCertsCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCertFromLoadBalancerCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/UploadSslCertCmd.java
>  PRE-CREATION 
>   api/src/org/apache/cloudstack/api/response/SslCertResponse.java 
> PRE-CREATION 
>   client/tomcatconf/applicationContext.xml.in 2a3520b 
>   client/tomcatconf/nonossComponentContext.xml.in 9d1da95 
>   core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java 3a51e8a 
>   
> engine/components-api/src/com/cloud/network/lb/LoadBalancingRulesManager.java 
> 3e32585 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapDao.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapDaoImpl.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapVO.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVO.java fee88cf 
>   engine/schema/src/com/cloud/network/dao/SslCertDao

Re: Review Request 14976: [SSL Termination support] Part2 : Assign certificates to LBs

[Murali Reddy]

On 06/11/13 12:40 AM, "Syed Ahmed"  wrote:

>
>
>> On Nov. 5, 2013, 9:43 a.m., Murali Reddy wrote:
>> > api/src/com/cloud/network/lb/LoadBalancingRule.java, lines 42-43
>> > 
>><https://reviews.apache.org/r/14976/diff/3/?file=374393#file374393line42>
>> >
>> > can you please add new constructors which takes ssl cert and
>>protocol. If we extend same constructor then its resulting unnecessary
>>changes in internal lb, elastic lb code as well.
>
>I have added an new constructor and removed all reverted all the
>invocations in internal lb and elastic lb code. I am sorry but I am not
>aware of the difference between different LB types in cloudstack. Is
>there some place where I can find more info on this ?
>
>
>On Nov. 5, 2013, 9:43 a.m., Syed Ahmed wrote:
>> > - i dont see certificate details in the load balancer response
>>obtained from listLoadBalancerRules.Does it make sense to give the
>>certificate details if there is a cert assigined to load balancer rule?
>> > 
>> > - i dont see code to add a network offering with
>>'SslTermination'capability. Also list network offering, should show if
>>LB service with SSL termination is supported by the offering.
>> > 
>> > - Please add Apache license header to all files.
>
>1) I was looking at the listLoadBalancerRules API and it does not list
>other things bound to the lb rule like stickiness policy or health check
>policy so I assumed that SSL certs being something like health check will
>not be in the response. If it makes sense to add them, I will gladly do
>so.

Yes, you are right. I was assuming that in load balancer response, there
should be details of associated stickiness policy etc, but looks like lb
response need to be fixed across the board. If its not too much of a
change please add the certificate details associated with lb rule in the
lb rule response.

> 
>
>2) So what you are saying is that Ssltermination will be a service
>offering like DNS, DHCP etc? Right now, if you see the
>NetscalerElement.java, I have just added the SslTermination capability as
>true. Does this suffice?

So there is network service and network service capabilities. I meant
'ssltermination' to be a capability of lb service. When you create network
offering, you can say 'LB' service and  service capability
'ssltermination' is enabled by the network offering. So in only networks
created with such network offering, SSL termination functionality can be
available.

Also, there need to be service capability matched against the advertised
capabilities of network service provider. For eg. If one creates network
offering which says LB service with SslCapability enabled with virtual
router providing LB service should fail because VR does not advertise the
capabilities in VirtualRouter Network Element. Same should succeed if
NetScaler is chosen as service provider because NetScaler element
advertised the capability.

> 
>
>3) Done

Re: Review Request 14976: [SSL Termination support] Part2 : Assign certificates to LBs

[Murali Reddy]

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


patch does not apply on master. please rebase with latest master and update the 
patch

- Murali Reddy


On Nov. 6, 2013, 12:54 a.m., Syed Ahmed wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14976/
> ---
> 
> (Updated Nov. 6, 2013, 12:54 a.m.)
> 
> 
> Review request for cloudstack, Darren Shepherd, Murali Reddy, and Sheng Yang.
> 
> 
> Bugs: CLOUDSTACK-4821
> https://issues.apache.org/jira/browse/CLOUDSTACK-4821
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This is the second patch for SSL termination support. This patch impletements 
> the assginement of certificate to loadbalancers. Support for netscaler is 
> also added. Due to the version of netscaler API in CS, I could not add 
> support for certificate chain. This should not be a big change however. We 
> can discuss this.
> 
> 
> NOTE: Because I cannot diff with my local branch, this patch also includes 
> the first patch which includes certificate management logic ... sorry 
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/LoadBalancerTO.java df2f8a8 
>   api/src/com/cloud/event/EventTypes.java a762606 
>   api/src/com/cloud/network/Network.java 49f380b 
>   api/src/com/cloud/network/lb/CertService.java PRE-CREATION 
>   api/src/com/cloud/network/lb/LoadBalancingRule.java 4b37782 
>   api/src/com/cloud/network/lb/LoadBalancingRulesService.java 59d5c8d 
>   api/src/com/cloud/network/lb/SslCert.java PRE-CREATION 
>   api/src/org/apache/cloudstack/api/ApiConstants.java c75e6a0 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCertToLoadBalancerCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/CreateLoadBalancerRuleCmd.java
>  a368436 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/DeleteSslCertCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListSslCertsCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCertFromLoadBalancerCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/UploadSslCertCmd.java
>  PRE-CREATION 
>   api/src/org/apache/cloudstack/api/response/SslCertResponse.java 
> PRE-CREATION 
>   client/tomcatconf/applicationContext.xml.in 2a3520b 
>   client/tomcatconf/nonossComponentContext.xml.in 9d1da95 
>   core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java 3a51e8a 
>   
> engine/components-api/src/com/cloud/network/lb/LoadBalancingRulesManager.java 
> 3e32585 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapDao.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapDaoImpl.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapVO.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVO.java fee88cf 
>   engine/schema/src/com/cloud/network/dao/SslCertDao.java PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/SslCertDaoImpl.java PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/SslCertVO.java PRE-CREATION 
>   
> plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
>  ab414de 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
>  b6269eb 
>   
> plugins/network-elements/internal-loadbalancer/test/org/apache/cloudstack/internallbvmmgr/InternalLBVMManagerTest.java
>  82f90fb 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/element/NetscalerElement.java
>  d63b14f 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  fe072e1 
>   server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java 
> dd48930 
>   server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java c685ee3 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> 3dfcad5 
>   server/src/com/cloud/server/ManagementServerImpl.java 699f469 
>   
> server/src/org/apache/cloudstack/network/lb/ApplicationLoadBalancerManagerImpl.java
>  2385edc 
>   server/src/org/apache/cloudstack/network/lb/CertServiceImpl.java 
> PRE-CREATION 
>   server/test/or

Re: Review Request 14976: [SSL Termination support] Part2 : Assign certificates to LBs

[Murali Reddy]

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


patch does not apply on master. please rebase with latest master and update the 
patch

- Murali Reddy


On Nov. 6, 2013, 12:54 a.m., Syed Ahmed wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14976/
> ---
> 
> (Updated Nov. 6, 2013, 12:54 a.m.)
> 
> 
> Review request for cloudstack, Darren Shepherd, Murali Reddy, and Sheng Yang.
> 
> 
> Bugs: CLOUDSTACK-4821
> https://issues.apache.org/jira/browse/CLOUDSTACK-4821
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This is the second patch for SSL termination support. This patch impletements 
> the assginement of certificate to loadbalancers. Support for netscaler is 
> also added. Due to the version of netscaler API in CS, I could not add 
> support for certificate chain. This should not be a big change however. We 
> can discuss this.
> 
> 
> NOTE: Because I cannot diff with my local branch, this patch also includes 
> the first patch which includes certificate management logic ... sorry 
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/LoadBalancerTO.java df2f8a8 
>   api/src/com/cloud/event/EventTypes.java a762606 
>   api/src/com/cloud/network/Network.java 49f380b 
>   api/src/com/cloud/network/lb/CertService.java PRE-CREATION 
>   api/src/com/cloud/network/lb/LoadBalancingRule.java 4b37782 
>   api/src/com/cloud/network/lb/LoadBalancingRulesService.java 59d5c8d 
>   api/src/com/cloud/network/lb/SslCert.java PRE-CREATION 
>   api/src/org/apache/cloudstack/api/ApiConstants.java c75e6a0 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCertToLoadBalancerCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/CreateLoadBalancerRuleCmd.java
>  a368436 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/DeleteSslCertCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListSslCertsCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCertFromLoadBalancerCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/UploadSslCertCmd.java
>  PRE-CREATION 
>   api/src/org/apache/cloudstack/api/response/SslCertResponse.java 
> PRE-CREATION 
>   client/tomcatconf/applicationContext.xml.in 2a3520b 
>   client/tomcatconf/nonossComponentContext.xml.in 9d1da95 
>   core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java 3a51e8a 
>   
> engine/components-api/src/com/cloud/network/lb/LoadBalancingRulesManager.java 
> 3e32585 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapDao.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapDaoImpl.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapVO.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVO.java fee88cf 
>   engine/schema/src/com/cloud/network/dao/SslCertDao.java PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/SslCertDaoImpl.java PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/SslCertVO.java PRE-CREATION 
>   
> plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
>  ab414de 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
>  b6269eb 
>   
> plugins/network-elements/internal-loadbalancer/test/org/apache/cloudstack/internallbvmmgr/InternalLBVMManagerTest.java
>  82f90fb 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/element/NetscalerElement.java
>  d63b14f 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  fe072e1 
>   server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java 
> dd48930 
>   server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java c685ee3 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> 3dfcad5 
>   server/src/com/cloud/server/ManagementServerImpl.java 699f469 
>   
> server/src/org/apache/cloudstack/network/lb/ApplicationLoadBalancerManagerImpl.java
>  2385edc 
>   server/src/org/apache/cloudstack/network/lb/CertServiceImpl.java 
> PRE-CREATION 
>   server/test/or

Re: Review Request 14976: [SSL Termination support] Part2 : Assign certificates to LBs

[Murali Reddy]

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

Ship it!


commit 0076307863e9155273d9e4c14282de429388c9e9
Author: Syed 
Date:   Wed Nov 6 15:08:42 2013 -0500

- Murali Reddy


On Nov. 6, 2013, 8:15 p.m., Syed Ahmed wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14976/
> ---
> 
> (Updated Nov. 6, 2013, 8:15 p.m.)
> 
> 
> Review request for cloudstack, Darren Shepherd, Murali Reddy, and Sheng Yang.
> 
> 
> Bugs: CLOUDSTACK-4821
> https://issues.apache.org/jira/browse/CLOUDSTACK-4821
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This is the second patch for SSL termination support. This patch impletements 
> the assginement of certificate to loadbalancers. Support for netscaler is 
> also added. Due to the version of netscaler API in CS, I could not add 
> support for certificate chain. This should not be a big change however. We 
> can discuss this.
> 
> 
> NOTE: Because I cannot diff with my local branch, this patch also includes 
> the first patch which includes certificate management logic ... sorry 
> 
> 
> Diffs
> -
> 
>   CHANGES 054e7b0 
>   api/src/com/cloud/agent/api/to/LoadBalancerTO.java df2f8a8 
>   api/src/com/cloud/event/EventTypes.java d9f80eb 
>   api/src/com/cloud/network/Network.java 318ac19 
>   api/src/com/cloud/network/lb/CertService.java PRE-CREATION 
>   api/src/com/cloud/network/lb/LoadBalancingRule.java 4b37782 
>   api/src/com/cloud/network/lb/LoadBalancingRulesService.java 59d5c8d 
>   api/src/com/cloud/network/lb/SslCert.java PRE-CREATION 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 3b2bc67 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCertToLoadBalancerCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/CreateLoadBalancerRuleCmd.java
>  a368436 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/DeleteSslCertCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListSslCertsCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCertFromLoadBalancerCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/UploadSslCertCmd.java
>  PRE-CREATION 
>   api/src/org/apache/cloudstack/api/response/SslCertResponse.java 
> PRE-CREATION 
>   client/tomcatconf/commands.properties.in 087d8b9 
>   core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java 3a51e8a 
>   
> engine/components-api/src/com/cloud/network/lb/LoadBalancingRulesManager.java 
> 3e32585 
>   
> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
>  98ef018 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapDao.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapDaoImpl.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerCertMapVO.java 
> PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVO.java fee88cf 
>   engine/schema/src/com/cloud/network/dao/SslCertDao.java PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/SslCertDaoImpl.java PRE-CREATION 
>   engine/schema/src/com/cloud/network/dao/SslCertVO.java PRE-CREATION 
>   
> plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
>  5c6f2e7 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
>  b6269eb 
>   
> plugins/network-elements/internal-loadbalancer/test/org/apache/cloudstack/internallbvmmgr/InternalLBVMManagerTest.java
>  82f90fb 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/element/NetscalerElement.java
>  8101864 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  fe072e1 
>   
> server/resources/META-INF/cloudstack/core/spring-server-core-managers-context.xml
>  5e37908 
>   server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java 
> 6ca40c0 
>   server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 0d43478 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> 9b35a4b 
>   server/src/com/cloud/server/ManagementServerImpl.java 79b20d0 
> 

Re: Review Request 15489: Adding protocol parameter to loadbalancer response

[Murali Reddy]

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


Syed I dont think you added 'protocol' to createLoadBalancerRule. There should 
not be 'protocol' in the LoadBalancerContainer?

- Murali Reddy


On Nov. 13, 2013, 6:08 p.m., Syed Ahmed wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15489/
> ---
> 
> (Updated Nov. 13, 2013, 6:08 p.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk and Murali Reddy.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Adding protocol parameter to Loadbalancer Response
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/rules/LoadBalancer.java e6dadca 
>   api/src/com/cloud/network/rules/LoadBalancerContainer.java 9d5ea59 
>   api/src/org/apache/cloudstack/api/response/LoadBalancerResponse.java 
> 0f18097 
>   
> engine/schema/src/org/apache/cloudstack/lb/ApplicationLoadBalancerRuleVO.java 
> 37a747e 
>   server/src/com/cloud/api/ApiResponseHelper.java 903c485 
> 
> Diff: https://reviews.apache.org/r/15489/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Syed Ahmed
> 
>

Re: Trunk interface to VM

[Murali Reddy]

If you can run XenServer on ESXi, there there is 'virtual guest
tagging'[1] where VLAN 4095 lets guest instances to send and receive
tagged traffic on to physical network. Perhaps you can try creating a
network with 4095 VLAN tag from CS and spin up XS VM instances.

You can do it on XenServer as well, but VIF needs to connect to a non-VLAN
network. I use NetScaler VPX on XenServer[2], where VPX sends and receives
tagged traffic from the XenServer.

[1] 
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di
splayKC&externalId=1003806
[2] 
http://support.citrix.com/proddocs/topic/netscaler-vpx-10/ns-vpx-overview-w
rapper-con.html

On 16/11/13 11:31 AM, "Francois Gaudreault" 
wrote:

>Yes. We want to be able spin XS within CloudStack. We also need those XS
>to
>consume VLAN tags to do advanced networking (kind of CS inside CS). Lets
>say we do have devs with ambitious needs :)
>
>Francois
>On 2013-11-15 9:46 PM, "Chiradeep Vittal" 
>wrote:
>
>> You want to pass the vlan tags into a VM that is actually a XenServer?
>>
>> On 11/14/13 3:02 PM, "Francois Gaudreault" 
>> wrote:
>>
>> >Is there a way to assign a trunked interface to a VM running in CS?
>>Like
>> >assign the entire guest interface. We have a use case where we need to
>>run
>> >XenServer hosts within a cloudstack managed infra.
>> >
>> >Thanks!
>> >
>> >Francois
>>
>>
>

Re: 3.0.x->4.1 DB upgrade: missing table for Netscaler

[Murali Reddy]

On 20/05/13 7:08 PM, "Chip Childers"  wrote:

>On Fri, May 17, 2013 at 08:30:26PM +, Alena Prokharchyk wrote:
>> Hi Murali,
>> 
>> I found that the table "netscaler_pod_ref" (introduced with your checkin
>> 3b1aca19) is missing on the upgraded setups. The table was introduced in
>> 40, but it never was a part of 302->40 db upgrade. So for customers
>> upgrading to 4.1 from 3.0.x, this table will be missed.
>> 
>> Could you please take a look in case I've missed the upgrade file where
>> this table is present. Otherwise, it has to become a part of 40->41
>> upgrade as the code for the feature is present in 4.1 branch.
>> 
>> -Alena.
>> 
>>
>
>Murali,
>
>Any update on this?
>
>-chip
>

Code and schema corresponding to commit 3b1aca19 is not in use, so does
not affect any functionality for 4.1. Unless there are concerns I will
skip fixing it for 4.1. I opened CLOUDSTACK-2587 to either fix the DB
upgrade or pull out unused code for 4.2.

Thanks Alena for pointing at missing upgrade.

Re: [DISCUSS] EIP Enhancements FS & Design Document

[Murali Reddy]

Swamy,

As mentioned in my merge request [1], I have generalised this feature and
tried to not enforce AWS EIP semantics. Please see the updated FS [2]

[1] http://s.apache.org/xjy
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+IP

Let me know if you need further clarification.

Thanks,
Murali

On 15/05/13 10:51 PM, "Venkata SwamyBabu Budumuru"
 wrote:

>Hi,
>
>I didn't find the old mail thread about this FS. Hence posting my review
>comments in a new thread.
>
>I have few queries/ comments after reviewing the FS [1]
>
>[1] https://cwiki.apache.org/CLOUDSTACK/eip-enhancements.html
>[2] Prior discussion thread :  http://sy.pe/6bNG
>
>
>1. Are we providing any flexibility for admin to impose no. of EIPs an
>account can use?
>2. As per the Spec, when an instance has a public ip with
>is_system=false, then we don't let user asosciateEIP. I feel, it would be
>better if allow the user to associate EIP in this case?
>3. When "Associate PublicIP" is false then are going to keep all the
>semantics to stand the same except the fact that vm deployment by default
>not getting the public ip?
>4. Do allow CS to reprogram NAT rules on the provider in case of n/w
>restarts?
>5. Under Scope, point 4 says that we only support static NAT on region
>level EIP. Is this true for advanced zones as well? we cannot we support
>other services like PF / LB etc..,?
>6. Can you confirm that we are supporting this for Shared n/ws in
>advanced zone?
>7. I see in the spec that "createElasticIpRange" API not having any VLAN
>id. Are we supporting region level IP CIDR with both tagged and untagged?
>multiple subnets in the same VLAN and different VLANs etc..,
>8. When there is an ElasticIp associated with instance, Does the current
>implementation release this IP and gives it back to account when VM got
>to stopped state? if yes, does this mean user has to associateEIP every
>time user starts instance?
>
>
>Thanks,
>SWAMY
>
>

Re: [DISCUSS] EIP Enhancements FS & Design Document

[Murali Reddy]

On 20/05/13 11:31 PM, "Chip Childers"  wrote:

>On Mon, May 20, 2013 at 02:19:24PM +, Murali Reddy wrote:
>> 
>> Swamy,
>> 
>> As mentioned in my merge request [1], I have generalised this feature
>>and
>> tried to not enforce AWS EIP semantics. Please see the updated FS [2]
>> 
>> [1] http://s.apache.org/xjy
>> [2] 
>> 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+IP
>> 
>> Let me know if you need further clarification.
>
>Do you want the older page to be deleted?  Is it still relevant?
>Perhaps we should move it to an abandoned designs parent page?

Its not relevant, left a note in the old FS mentioning it as obsolete.
Also moved the spec out of 4.2 design documents to 'designs not committed
for any release' for now.

>
>> 
>> Thanks,
>> Murali
>> 
>> On 15/05/13 10:51 PM, "Venkata SwamyBabu Budumuru"
>>  wrote:
>> 
>> >Hi,
>> >
>> >I didn't find the old mail thread about this FS. Hence posting my
>>review
>> >comments in a new thread.
>> >
>> >I have few queries/ comments after reviewing the FS [1]
>> >
>> >[1] https://cwiki.apache.org/CLOUDSTACK/eip-enhancements.html
>> >[2] Prior discussion thread :  http://sy.pe/6bNG
>> >
>> >
>> >1. Are we providing any flexibility for admin to impose no. of EIPs an
>> >account can use?
>> >2. As per the Spec, when an instance has a public ip with
>> >is_system=false, then we don't let user asosciateEIP. I feel, it would
>>be
>> >better if allow the user to associate EIP in this case?
>> >3. When "Associate PublicIP" is false then are going to keep all the
>> >semantics to stand the same except the fact that vm deployment by
>>default
>> >not getting the public ip?
>> >4. Do allow CS to reprogram NAT rules on the provider in case of n/w
>> >restarts?
>> >5. Under Scope, point 4 says that we only support static NAT on region
>> >level EIP. Is this true for advanced zones as well? we cannot we
>>support
>> >other services like PF / LB etc..,?
>> >6. Can you confirm that we are supporting this for Shared n/ws in
>> >advanced zone?
>> >7. I see in the spec that "createElasticIpRange" API not having any
>>VLAN
>> >id. Are we supporting region level IP CIDR with both tagged and
>>untagged?
>> >multiple subnets in the same VLAN and different VLANs etc..,
>> >8. When there is an ElasticIp associated with instance, Does the
>>current
>> >implementation release this IP and gives it back to account when VM got
>> >to stopped state? if yes, does this mean user has to associateEIP every
>> >time user starts instance?
>> >
>> >
>> >Thanks,
>> >SWAMY
>> >
>> >
>> 
>> 
>> 
>

[ACS41][Patch Request]

[Murali Reddy]

Chip, please cherry-pick to 4.1

CLOUDSTACK-2587: netscaler_pod_ref DB upgrade is missing from 3.0.2 to 4.x

added missing schema as part of 4.0 to 4.1 upgrade

Branch: refs/heads/master
Commit: 623a26e469ca7354a7dbe6b8954276985e289687
Parents: cc49230
Author: Murali Reddy mailto:muralimmre...@gmail.com>>
Authored: Thu May 23 21:59:32 2013 +0530
Committer: Murali Reddy 
mailto:muralimmre...@gmail.com>>
Committed: Thu May 23 22:28:17 2013 +0530

Re: [ACS41] Outstanding items

[Murali Reddy]

On 23/05/13 10:43 PM, "Chip Childers"  wrote:

>CLOUDSTACK-2215
>ACS41 SSVM does not use allocated storage ip range
>
>The bug above needs to have my questions addressed.  Is this (1)
>reproducible and (2) is it really a blocker if it is reproducible?
>
>The other outstanding issue for 4.1.0 are the questions from Alena to
>Murali and Frank posed in the email with subject="40-41 upgrade".  We
>need an answer on those questions guys!
>
>-chip
>

Sent patch request for 4.1, for the issue raised for the bug
'CLOUDSTACK-2587: netscaler_pod_ref DB upgrade is missing from 3.0.2 to
4.x'

Patch will address both missing schema and global config parameters.

Re: Review Request: fixed vpc private gateway args to script

[Murali Reddy]

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

Ship it!


d8f5f2ea10eca540c10e93469fd5307fe25f0959

- Murali Reddy


On May 24, 2013, 12:38 p.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11372/
> ---
> 
> (Updated May 24, 2013, 12:38 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Murali Reddy, and Koushik 
> Das.
> 
> 
> Description
> ---
> 
> fixed vpc private gateway script args for vmware
> 
> 
> This addresses bug CLOUDSTACK-2671.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  be47754 
> 
> Diff: https://reviews.apache.org/r/11372/diff/
> 
> 
> Testing
> ---
> 
> Done
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

[DISCUSS] portable IP vs public IP

[Murali Reddy]

In CloudStack, currently there are four distinct operations available with
public IP's at network service and manager layers.

1. Acquiring a public IP from zone level public IP pool
2. Associate acquired public IP with a guest network/VPC
3. Disassociate an associated public IP with a guest network/VPC
4. Release acquired public IP

But at API, #1, #2 are rolled in to 'associateIpAddress' so an acquired
public IP is always associated with a network. Similarly #3, #4 is rolled
into 'disassociateIpAddress' API. Operations #2, #3 are not exposed
through the API layer. So in effect,

  - Public IP are always need to be associated with a network/VPC
  - Network rules for LB/PF/NAT etc expects that public IP is already
associated with the network
  - On network/VPC delete CloudStack implicitly releases acquired public
IP's by the user.
  - There is no way to transfer association of a public IP from a guest
network/VPC to another guest network/VPC. This is commonly used pattern to
mask the failures in AWS [2].

As part of the portable IP feature [1], I have relaxed these
restriction for portable IP's. So an acquired portable IP need not be
associated with a guest network/VPC always and association can be
transferred across the networks. For e.g on acquired portable IP, when an
user enables static NAT for a portable IP to VM1 in network1, disables
static NAT to VM1 and then enables static NAT with VM2 in network2,
CloudStack will implicitly transfers the association of the portable IP
from network1 to network2.

What I want to bring to discussion is portability as characteristic of
public IP vs special pool of public IP's. I have made portable IP's to be
a region level resource, which enables portable IP's association be
transferable across the networks in different zones of a region. But
portability semantics can be implemented for zone level public IP as well,
with restriction that association can be transferred across guest networks
in same physical network of a zone. This seems to me an useful
functionality to have for zone level public IP. I have extended
'associateIpAddress' API to specify a boolean flag 'is_portable' that
indicates user is requesting a portable IP. In the current implementation
this flag is interpreted as request for allocating region level public IP
pool. If it make sense then I can relax this restriction with minimal
change to indicate 'is_portable' as portable characteristics of public IP.
So 'is_portable' flag can be used irrespective of region level or zone
level public IP. And then introduce another flag to 'associateIpAddress'
API, that explicitly requests that an IP  from region level pool should be
allocated which by default can be moved across the networks from different
zones in that region.

Effort I am proposing is to get API semantics right with minimal changes.
I am not proposing to enable portability for zone level public Ip's for
4.2 but can be done for later release. Please comment.

[1]https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+I
P
[2]http://en.clouddesignpattern.org/index.php/CDP:Floating_IP_Pattern

Re: [DISCUSS] portable IP vs public IP

[Murali Reddy]

On 28/05/13 11:42 PM, "Chip Childers"  wrote:
>
>+1 to this proposal (with one concern noted below).
>
>> 
>> Effort I am proposing is to get API semantics right with minimal
>>changes.
>> I am not proposing to enable portability for zone level public Ip's for
>> 4.2 but can be done for later release. Please comment.
>
>Does it make sense to actually get the API for 4.2 to match this
>proposal?  Once we release it, changing the meaning really means
>breaking the contract, right?

I was not clear in my mail. Yes, my intention is to get the API right for
4.2 so that it can be extended cleanly in later releases.

>
>> 
>> 
>>[1]https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public
>>+I
>> P
>> [2]http://en.clouddesignpattern.org/index.php/CDP:Floating_IP_Pattern
>> 
>> 
>

Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze

[murali reddy]

We should do a health-check of proposed features [1] which are at risk for
4.2 feature freeze before deciding to re-evaluate timelines.

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2+Design+Documents


On Thu, May 30, 2013 at 10:04 AM, Chip Childers
wrote:

> On May 29, 2013, at 7:59 PM, John Burwell  wrote:
>
> > All,
> >
> > Since we have taken an eight (8) week delay completing the 4.1.0
> release, I would like propose that we re-evaluate the timelines for the
> 4.2.0 release.  When the schedule was originally conceived, it was intended
> that the project would have eight (8) weeks to focus exclusively on 4.2.0
> development.  Unfortunately, this delay has created an unfortunate conflict
> between squashing 4.1.0 bugs and completing 4.2.0 features.  I propose that
> we acknowledge this schedule impact, and push back the 4.2.0 feature freeze
> date by eight (8) weeks to 2 August 2013.  This delay will give the project
> time to properly review merges and address issues holistically, and,
> hopefully, relieve a good bit of the stress incurred by the simultaneous
> 4.1.0 and 4.2.0 activities.
> >
> > Thanks,
> > -John
>
> This is a reasonable idea IMO. I'd probably only extend by a month
> personally, but your logic is sound.  I'd much rather have reasoned
> discussions about code than argue procedural issues about timing any
> day. This might help facilitate that on some of the features folks are
> scrambling to complete.
>
> Others?
>

Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze

[Murali Reddy]

Yes. We agreed on time based release. I am failing to see what would extending 
freeze date will achieve.

On 30-May-2013, at 12:34 PM, David Nalley  wrote:

> On Thu, May 30, 2013 at 3:02 AM, murali reddy  wrote:
>> We should do a health-check of proposed features [1] which are at risk for
>> 4.2 feature freeze before deciding to re-evaluate timelines.
> 
> We are supposedly doing time-based release, so we don't care about
> what features make it versus don't.
> 
> --David

Re: Review Request: Updated account and domain id for nic secondary ips for shared networks

[Murali Reddy]

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


Should set the owner to be entity owner passed as ipowner instead of caller.

- Murali Reddy


On May 28, 2013, 7:27 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11458/
> ---
> 
> (Updated May 28, 2013, 7:27 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Description
> ---
> 
> Updated account and domain id for nic secondary ips for shared networks.
> Fixed by getting accoundId and domainId from the caller instead of network
> 
> 
> This addresses bug CLOUDSTACK-2609.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkServiceImpl.java f880bcc 
> 
> Diff: https://reviews.apache.org/r/11458/diff/
> 
> 
> Testing
> ---
> 
> Tested on isolated and shared networks.
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: event bus details

[Murali Reddy]

Marcus,

Events bus framework with current AMQP default implementation, has routing
key with format 
'Eventsource.EventCategory.EventType.EntityType.EntityUUID' as described
in [1]. If you see from the log you pasted below events of type
'ResourceStateEvent' has details of entity UUID. Since it was new event
type and was added in 4.1 it was easy to design so that all the entity
details are published. Also intention of this event was for programatic
consumption of events by external entities.

Action Events existed from long time, and was implemented and used
primarily for auditing messages for non-programmtic use. Unfortunately
there is huge number of places for different actions corresponding to
different entities need to be cleaned up. Please file a bug for some one
to pick it up and work on it.

[1] http://s.apache.org/MZS

Thanks,
Murali

On 25/06/13 9:53 AM, "Marcus Sorensen"  wrote:

>Here's another, when deleting a VPC. I see the details of all of the
>things it's doing (removing the router, networks, etc), but I can't
>tell which VPC was being deleted. I feel like that '*' under
>ActionEvent should be telling me the uuid, like that position does in
>the other events:
>
>[x] 
>'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled","e
>vent":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","user"
>:"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
> [x] 
>'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0-
>473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old
>-state":"Running","new-state":"Stopping","resource":"Network"}'
> [x] 
>'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07-
>aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236"
>,"old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
> [x] 
>'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-ae
>d0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","
>old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
> [x] 
>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d42
>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","o
>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
> [x] 
>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d42
>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","o
>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
> [x] 
>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d
>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a",
>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
> [x] 
>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d
>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a",
>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>...
>
>On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen 
>wrote:
>> Hi all,
>>I've been playing around with the new event bus, trying to see if
>> it could be useful, and I'm a bit confused about the output. If I
>> subscribe to all topics, and try to reboot a virtual machine, this is
>> all I see:
>>
>> 
>>'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"Sc
>>heduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014c
>>04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>
>> I see the account info, but nothing about which VM is being rebooted.
>>
>> If I try to stop/start a VM, I likewise see no details in the
>> ActionEvent, about the subject being acted upon:
>>
>> 
>>'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Sche
>>duled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d"
>>,"user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>
>> I do however see some details regarding a 'Network' resource, though
>> if I were to write something to parse this output I wouldn't
>> immediately know that it was related to a VM (note the 'id' here
>> actually matches the VM I'm stopping, but there's nothing in the event
>> to tell me it's a VM):
>>
>> 
>>'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3b
>>-4e8b-8fb2-268ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-268ec32c","o
>>ld-state":"Running","new-state":"Stopping","resource":"Network"}'
>>
>> I'm just subscribing to "#", so I assume I'm getting everything, but
>> I'm just having trouble making sense of the output.
>

Re: event bus details

[Murali Reddy]

Opened bug CLOUDSTACK-3190 for this.

On 25/06/13 4:03 PM, "Murali Reddy"  wrote:

>
>Marcus,
>
>Events bus framework with current AMQP default implementation, has routing
>key with format 
>'Eventsource.EventCategory.EventType.EntityType.EntityUUID' as described
>in [1]. If you see from the log you pasted below events of type
>'ResourceStateEvent' has details of entity UUID. Since it was new event
>type and was added in 4.1 it was easy to design so that all the entity
>details are published. Also intention of this event was for programatic
>consumption of events by external entities.
>
>Action Events existed from long time, and was implemented and used
>primarily for auditing messages for non-programmtic use. Unfortunately
>there is huge number of places for different actions corresponding to
>different entities need to be cleaned up. Please file a bug for some one
>to pick it up and work on it.
>
>[1] http://s.apache.org/MZS
>
>Thanks,
>Murali
>
>On 25/06/13 9:53 AM, "Marcus Sorensen"  wrote:
>
>>Here's another, when deleting a VPC. I see the details of all of the
>>things it's doing (removing the router, networks, etc), but I can't
>>tell which VPC was being deleted. I feel like that '*' under
>>ActionEvent should be telling me the uuid, like that position does in
>>the other events:
>>
>>[x] 
>>'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled","
>>e
>>vent":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","user
>>"
>>:"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>> [x] 
>>'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0
>>-
>>473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","ol
>>d
>>-state":"Running","new-state":"Stopping","resource":"Network"}'
>> [x] 
>>'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07
>>-
>>aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236
>>"
>>,"old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
>> [x] 
>>'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-a
>>e
>>d0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236",
>>"
>>old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
>> [x] 
>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d4
>>2
>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","
>>o
>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>> [x] 
>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d4
>>2
>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","
>>o
>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>> [x] 
>>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-
>>d
>>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>,
>>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>> [x] 
>>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-
>>d
>>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>,
>>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>>...
>>
>>On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen 
>>wrote:
>>> Hi all,
>>>I've been playing around with the new event bus, trying to see if
>>> it could be useful, and I'm a bit confused about the output. If I
>>> subscribe to all topics, and try to reboot a virtual machine, this is
>>> all I see:
>>>
>>> 
>>>'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"S
>>>c
>>>heduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014
>>>c
>>>04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>
>>> I see the account info, but nothing about which VM is being rebooted.
>>>
>>> If I try to stop/start a VM, I likewise see no details in the
>>> ActionEvent, about the subject being acted upon:
>>>
>>> 
>>>'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Sch
>>>e
>>>duled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d
>>>"
>>>,"user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>
>>> I do however see some details regarding a 'Network' resource, though
>>> if I were to write something to parse this output I wouldn't
>>> immediately know that it was related to a VM (note the 'id' here
>>> actually matches the VM I'm stopping, but there's nothing in the event
>>> to tell me it's a VM):
>>>
>>> 
>>>'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3
>>>b
>>>-4e8b-8fb2-268ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-268ec32c","
>>>o
>>>ld-state":"Running","new-state":"Stopping","resource":"Network"}'
>>>
>>> I'm just subscribing to "#", so I assume I'm getting everything, but
>>> I'm just having trouble making sense of the output.
>>
>
>
>

Re: event bus details

[Murali Reddy]

Yeah its a bug. Fixed CLOUDSTACK-3213 for both 4.2 and 4.1.1. Thanks for
bringing it out.

On 25/06/13 9:27 PM, "Marcus Sorensen"  wrote:

>Thanks for the response. So am I to assume that the VM start/stop
>showing up under EntityType Network is also a bug?
>
>On Tue, Jun 25, 2013 at 6:05 AM, Murali Reddy 
>wrote:
>>
>> Opened bug CLOUDSTACK-3190 for this.
>>
>> On 25/06/13 4:03 PM, "Murali Reddy"  wrote:
>>
>>>
>>>Marcus,
>>>
>>>Events bus framework with current AMQP default implementation, has
>>>routing
>>>key with format
>>>'Eventsource.EventCategory.EventType.EntityType.EntityUUID' as described
>>>in [1]. If you see from the log you pasted below events of type
>>>'ResourceStateEvent' has details of entity UUID. Since it was new event
>>>type and was added in 4.1 it was easy to design so that all the entity
>>>details are published. Also intention of this event was for programatic
>>>consumption of events by external entities.
>>>
>>>Action Events existed from long time, and was implemented and used
>>>primarily for auditing messages for non-programmtic use. Unfortunately
>>>there is huge number of places for different actions corresponding to
>>>different entities need to be cleaned up. Please file a bug for some one
>>>to pick it up and work on it.
>>>
>>>[1] http://s.apache.org/MZS
>>>
>>>Thanks,
>>>Murali
>>>
>>>On 25/06/13 9:53 AM, "Marcus Sorensen"  wrote:
>>>
>>>>Here's another, when deleting a VPC. I see the details of all of the
>>>>things it's doing (removing the router, networks, etc), but I can't
>>>>tell which VPC was being deleted. I feel like that '*' under
>>>>ActionEvent should be telling me the uuid, like that position does in
>>>>the other events:
>>>>
>>>>[x]
>>>>'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled"
>>>>,"
>>>>e
>>>>vent":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","us
>>>>er
>>>>"
>>>>:"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-ae
>>>>d0
>>>>-
>>>>473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","
>>>>ol
>>>>d
>>>>-state":"Running","new-state":"Stopping","resource":"Network"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e
>>>>07
>>>>-
>>>>aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb2
>>>>36
>>>>"
>>>>,"old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07
>>>>-a
>>>>e
>>>>d0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236
>>>>",
>>>>"
>>>>old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-
>>>>d4
>>>>2
>>>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>>>,"
>>>>o
>>>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-
>>>>d4
>>>>2
>>>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>>>,"
>>>>o
>>>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da
>>>>7-
>>>>d
>>>>428-4f6

Re: event bus details

[Murali Reddy]

On 27/06/13 5:46 AM, "Ryan Dietrich"  wrote:

>Hi, I'm doing some work in the event bus.  My requirements are pretty
>straightforward.
>
>1. Let me know when a command is executed.
>2. Let me know the UUID of the element being modified when that command
>is executed. (i.e.: If we're updating a virtual machine, the UUID should
>be the one for that particular VM).

For every api command, pretty much there is an action event generated that
gets published on to event bus as well. CLOUDSTACK-3190 is open bug that
needs to be fixed so that entity type being operated and UUID details of
entity are published. It just tedious job to fix all the places action
events are generated. Good pick for CloudStack newbie to fix it though.

>3. When an async command is executed, let me know when it's started, and
>every state change for that job until it is completed, and then let me
>know what the status of the job is.

This should be doable with a quick fix. I opened CLOUDSTACK-3233 for this.
Would you mind take a look at this bug and see if you can fix it? I left
details on what needs to be done in the bug.

>4. I'd like to see the human readable username and domain of the user
>that is executing the command. (I understand this one isn't as important
>to many of you, a configuration option would suffice).
>5. Lastly, I'd like to get state changes of the various components should
>be sent to the event bus, again with the user/domanin/uuid.

There is RESOURCE_STATE_CHANGE_EVENT's that get published on resource
state change of critical entities VM, network, volume, snapshot. But there
is entity type and entity UUID details only. If you feel user/domain
details are needed as well please go ahead and fix message body.

>
>ActionEvent seems driven either directly, or via annotation
>(api/src/com/cloud/event/ActionEvent.java), and relies on overrides to
>get the actual description (not sure why there is a description there at
>all actually).
>The other "StateListener" / "StateEvent" systems seem totally unrelated,
>yet encompass an alternative approach to writing messages to the event
>bus (and have a bit more meta-data that I need).
>
>Are the things I'm looking to do the actual desired use case for the
>event bus?  

Absolutely valid use cases. Please do bring out the feedback, we can at
least fix it in 4.2.

>Human readable descriptions aren't enough for me, I really need machine
>consumable consistent messaging (currently it seems every message being
>pushed out to RabbitMQ follows a different format).  Is there any
>documentation or plan for this system going forward?

Event message body is key-value pair in JSON format. Body format may
differ depending on the event category (action event, usage event,
resource state change, alert). Can you please check if for a event
category message are consistent? If its not please open bug.

>
>I need this working, now-ish, so I'm willing to get in and get it done,
>but again, I'd rather work with the flow, and not against it :-)
>
>Cheers,
>
>-Ryan Dietrich
>
>On Jun 26, 2013, at 8:14 AM, Murali Reddy  wrote:
>
>> 
>> Yeah its a bug. Fixed CLOUDSTACK-3213 for both 4.2 and 4.1.1. Thanks for
>> bringing it out.
>> 
>> On 25/06/13 9:27 PM, "Marcus Sorensen"  wrote:
>> 
>>> Thanks for the response. So am I to assume that the VM start/stop
>>> showing up under EntityType Network is also a bug?
>>> 
>
>

Re: event bus details

[Murali Reddy]

On 28/06/13 4:28 AM, "Ryan Dietrich"  wrote:

>> For every api command, pretty much there is an action event generated
>>that
>> gets published on to event bus as well. CLOUDSTACK-3190 is open bug that
>> needs to be fixed so that entity type being operated and UUID details of
>> entity are published. It just tedious job to fix all the places action
>> events are generated. Good pick for CloudStack newbie to fix it though.
>
>Yes, my assumption is you'd have to add another abstract method on
>BaseAsyncCmd to allow you to query for the UUID being modified.
>The problem with this is, many of the UUID's passed into commands are
>transformed into their internal ID (long) via the "Parameter" annotation.
>It would seem sort of ugly to have to re-query the UUID out of the
>database so it would be available when the job details needed to be
>published.
>
>Is there any way to get raw access to the parameters sent to a command?
>
>> This should be doable with a quick fix. I opened CLOUDSTACK-3233 for
>>this.
>> Would you mind take a look at this bug and see if you can fix it? I left
>> details on what needs to be done in the bug.
>
>Ok, I'm working on this now.
>
>> There is RESOURCE_STATE_CHANGE_EVENT's that get published on resource
>> state change of critical entities VM, network, volume, snapshot. But
>>there
>> is entity type and entity UUID details only. If you feel user/domain
>> details are needed as well please go ahead and fix message body.
>
>I will, I planned on using a configuration option to allow you to
>show/hide this extra information.  I'll need it, but I understand that
>others might see this as bloat.  (I'm making it default to "false").
>
>> Event message body is key-value pair in JSON format. Body format may
>> differ depending on the event category (action event, usage event,
>> resource state change, alert). Can you please check if for a event
>> category message are consistent? If its not please open bug.
>
>Sure, here's a couple quick examples.
>
>management-server.AlertEvent.ALERT-USAGE.*.*   {"event":"ALERT.USAGE"}
>management-server.ResourceStateEvent.OperationSucceeded.Volume.bb213f8b-d7
>c8-4f7d-82bd-8e4ed230eb66
>{"id":"bb213f8b-d7c8-4f7d-82bd-8e4ed230eb66","old-state":"Snapshotting","n
>ew-state":"Ready","resource":"Volume"}
>management-server.ActionEvent.VM-CREATE.VirtualMachine.*
>{"status":"Scheduled","event":"VM.CREATE","account":"f66d4d60-bbdf-11e2-8b
>b5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}
>management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.dc802b
>ce-15f5-4694-be44-096d6aefca80
>{"id":"dc802bce-15f5-4694-be44-096d6aefca80","event":"VOLUME.DELETE","reso
>urce":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-525400
>14c04d","zone":"5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4"}
>
>So, within each EventCategory, things are consistent, but between them
>they are totally different.  When using say, GSON as the parsing routine
>you're force to do one of two things when receiving messages.
>
>1. Look at the routing key with a regex or "indexOf" call to figure out
>what kind of message you're receiving.
>2. Create a superset object that has all of the possible keys that
>compose all of the messages, and then use GSON to slurp everything in.
>Then you'd have to just check which fields were NULL to figure out what
>type of message you're dealing with.
>
>Both of these solutions seem poor.

Okay. When I designed I did not think of somebody consuming the message
directly. Since it was framework to both publish and subscribe, I sort of
added the necessary details in the payload
(framework/events/src/org/apache/cloudstack/framework/events/Event.java)
that a callback ( registered through subscribe in
framework/events/src/org/apache/cloudstack/framework/events/EventBus.java).
 Please go ahead and add the details to message body.


>  Obviously a resource event is different than a usage event, but if they
>were at least consistent at some level I wouldn't have to have super
>explicit code paths for every type of message being sent.  If I had to
>choose from any of the existing formats, I like the ResourceStateEvent
>the best.  It clearly shows you what the type of the UUID (volume in the
>example) as well as the state change.  ActionEvent, AlertEvent need some
>help.  

You are right, since ResourceStateEvent is newly added its built up on
EventBus, but legacy events definitely need help.

>
>Lastly, UsageEvent.  I'm almost confused what this means.  Here's an
>example from my logs.
>
>management-server.ResourceStateEvent.DestroyRequested.Volume.ed51b63b-a63b
>-4e6a-8c36-45f32c29988d
>{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","old-state":"Ready","new-stat
>e":"Destroy","resource":"Volume"}
>management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.ed51b6
>3b-a63b-4e6a-8c36-45f32c29988d
>{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","event":"VOLUME.DELETE","reso
>urce":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-52540

Re: Async Job / Event Bus issue

[Murali Reddy]

What do we break if we fix it now? Since instance id, instance type are
also part of the 'AsyncJobResponse' its appropriate to pass full details.
Clearly from the Ryan use case, details of job are needed by external
systems and since this is the only book-keeping of a job, we need to
retain the history.

On 03/07/13 4:12 AM, "Kelven Yang"  wrote:

>Fields in job record are tend to be used to reflect job status in job's
>life cycle instead of history.
>
>Kelven
>
>On 7/2/13 1:35 PM, "Ryan Dietrich"  wrote:
>
>>Ok.  I see the "reset attached object" calls now.
>>
>>I'm curious why those columns are being wiped out.  If you wanted to see
>>outstanding calls for an ID or Type, wouldn't you just query where the
>>jobStatus is still equal to zero?
>>
>>Wiping out those columns seems to destroy history, no?
>>
>>On Jul 2, 2013, at 2:27 PM, Alena Prokharchyk
>> wrote:
>>
>>> Ryan,
>>> 
>>> Those fields were added to indicate the instances (volumes, vms, etc)
>>> having pending/active async jobs. The customers' main use case was - by
>>> instance id, find out the jobs that are currently being executed for
>>>this
>>> instance. Once the job is completed, the field is offset to NULL.
>>> 
>>> -Alena.
>>
>
>

Re: event bus details

[Murali Reddy]

On 02/07/13 7:45 PM, "Ryan Dietrich"  wrote:

>Patch submitted.
>
>https://reviews.apache.org/r/12223/

Thanks for the patch. Added some comments to the review. Cloudstack group
is missing as reviewer, don't have permission to edit the review, so could
you please add group to the reviewers?

>
>Things that still need to be thought through:
>
>1. Should the async command event type be a column on async job (and be
>an attribute of AsyncJobVO)?
>2. Should getInstanceId and getInstanceType of AsyncCmd be abstract
>instead of implemented with null values? (would require updating every
>async command in the system, and would break everyones async plugin
>commands)
>
>Oh, and after figuring out how the parameter annotation works (and
>ApiDispatcher uses reflection to iterate over parameters, ugh), I saw
>BaseCmd.java has a HashMap of the arguments passed in
>from the user.
>I went with the APIDBUtils query function for UUID's because I saw no
>precedent for accessing that HashMap after initial argument handling.
>
>-Ryan Dietrich

Re: Review Request 12223: Async jobs actions now trigger event bus messages to be published

[Murali Reddy]

On 03/07/13 9:02 PM, "Ryan Dietrich"  wrote:

>
>
>> On July 3, 2013, 9:04 a.m., Murali Reddy wrote:
>> > server/src/com/cloud/async/AsyncJobManagerImpl.java, lines 147-156
>> > 
>><https://reviews.apache.org/r/12223/diff/3/?file=314993#file314993line147
>>>
>> >
>> > IMO this is not right. event type in asyn job are used for
>>'action events' which are basically user actions. Since we are just
>>dealing with 'asyn job' events its more appropriate events would be like
>>schedule of a new job, completion of job, status update of job etc.
>>Ofcourse you are adding details like instance/entity type and its UUID,
>>and command type etc which makes this event meaningful any way.
>
>It's the event type OF the command that the async job is performing.
>It's part of the abstract class that you're forced to implement when
>deriving from BaseAsyncCmd!  Not having it would be a mistake,

My concern was this event category becoming redundant of action events. I
would imagine use case for asyn job events, would be to fire an CloudStack
API which is asyn, and instead of polling management server for job status
be able to get the callback when job is done. Since you have already added
the job status (submit/complete/update) as event type for this async job
event category I am fine with the patch you submitted. Applied it on both
master and 4.2.

> I thought you'd comment on the fact that I'm substring-ing it out of
>JSON instead of just creating a new database column within AsyncJobVO.

I guess current approach Is fine. Event type is not primary attribute of
Async Job.

>
>
>> On July 3, 2013, 9:04 a.m., Murali Reddy wrote:
>> > server/src/com/cloud/async/AsyncJobManagerImpl.java, line 161
>> > 
>><https://reviews.apache.org/r/12223/diff/3/?file=314993#file314993line161
>>>
>> >
>> > Like mentioned in above comment, it would be appropriate we
>>capture schedule/complete/status update of async job here
>
>No problem.  I'll add an argument to the publish function.  It's called
>in three places.  Once for submit, once for update and once for complete.
> It'll be a simple string argument that will be captured and sent within
>the event description.
>
>
>> On July 3, 2013, 9:04 a.m., Murali Reddy wrote:
>> > server/src/com/cloud/async/AsyncJobManagerImpl.java, line 162
>> > 
>><https://reviews.apache.org/r/12223/diff/3/?file=314993#file314993line162
>>>
>> >
>> > any way we have instance id and instance UUID, please use them to
>>form routing key.
>
>But what if we don't?  Are you saying to make getInstanceId /
>getInstanceType abstract, forcing all async commands to implement those
>function?  Right now they have null returning definitions, which makes
>this line of code make sense.

Yeah, I noticed not all commands have implemented, probability need an
effort to clean it up and make the methods abstract. Can you please file a
bug for this?

>
>
>> On July 3, 2013, 9:04 a.m., Murali Reddy wrote:
>> > server/src/com/cloud/async/AsyncJobManagerImpl.java, line 173
>> > 
>><https://reviews.apache.org/r/12223/diff/3/?file=314993#file314993line173
>>>
>> >
>> > Internal id's are not exposed. Since UUID is populated in the
>>description that should be enough.
>
>Cool, I'll make that change.
>
>
>- Ryan
>
>
>---
>This is an automatically generated e-mail. To reply, visit:
>https://reviews.apache.org/r/12223/#review22704
>---
>
>
>On July 3, 2013, 2:17 p.m., Ryan Dietrich wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/12223/
>> ---
>> 
>> (Updated July 3, 2013, 2:17 p.m.)
>> 
>> 
>> Review request for cloudstack, Marcus Sorensen and Murali Reddy.
>> 
>> 
>> Bugs: CLOUDSTACK-3190
>> 
>> 
>> Repository: cloudstack-git
>> 
>> 
>> Description
>> ---
>> 
>> Updated AsyncJobManagerImpl to publish async job events when async jobs
>>are created, updated and completed.
>> I am currently stashing the command event description in the
>>commandInfo structure, and then pulling it back out as needed.
>> I could switch this to make a database change, but that seemed like a
>>more invasive change.
>> 
>> I have further diffs to clean up ActionEvent and AlertEvent as well.
>> 
>> 
>> Diffs
>> -
>> 
>>   api/src/com/cloud/event/EventCategory.java cee6529
>>   server/src/com/cloud/api/ApiServer.java 0cd1d61
>>   server/src/com/cloud/async/AsyncJobManagerImpl.java 0101a8a
>> 
>> Diff: https://reviews.apache.org/r/12223/diff/
>> 
>> 
>> Testing
>> ---
>> 
>> Manual testing only at this point.  I am more than willing to write a
>>python test using marvin, but I'm unsure if marvin has rabbitmq library
>>support or not yet.  Please advise.
>> 
>> 
>> Thanks,
>> 
>> Ryan Dietrich
>> 
>>
>
>

Re: Review Request 12223: Async jobs actions now trigger event bus messages to be published

[Murali Reddy]

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

Ship it!


70f33efa7250d1ac8022f4390cddcbcb62ba92f8 master
e7c8a35c3aca4722666c6f6ff6bc9caac46e17c3 4.2

- Murali Reddy


On July 3, 2013, 3:58 p.m., Ryan Dietrich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12223/
> ---
> 
> (Updated July 3, 2013, 3:58 p.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Murali Reddy.
> 
> 
> Bugs: CLOUDSTACK-3190
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Updated AsyncJobManagerImpl to publish async job events when async jobs are 
> created, updated and completed.
> I am currently stashing the command event description in the commandInfo 
> structure, and then pulling it back out as needed.
> I could switch this to make a database change, but that seemed like a more 
> invasive change.
> 
> I have further diffs to clean up ActionEvent and AlertEvent as well.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/event/EventCategory.java cee6529 
>   server/src/com/cloud/api/ApiServer.java 0cd1d61 
>   server/src/com/cloud/async/AsyncJobManagerImpl.java 0101a8a 
> 
> Diff: https://reviews.apache.org/r/12223/diff/
> 
> 
> Testing
> ---
> 
> Manual testing only at this point.  I am more than willing to write a python 
> test using marvin, but I'm unsure if marvin has rabbitmq library support or 
> not yet.  Please advise.
> 
> 
> Thanks,
> 
> Ryan Dietrich
> 
>

Re: Review Request 12278: CLOUDSTACK-3384: CloudStack allow VLAN range between 0-4096. Should be 0-'4095'.

[Murali Reddy]

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

Ship it!


Branch: refs/heads/master
Commit: 814630c5428862aa247914e5bc04c3bcbc00c501

Branch: refs/heads/4.2
Commit: a93042674134ded31d0dea2d006fac881743ab91

- Murali Reddy


On July 5, 2013, 8:14 p.m., Toshiaki Hatano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12278/
> ---
> 
> (Updated July 5, 2013, 8:14 p.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk, Chiradeep Vittal, Murali 
> Reddy, Hugo Trippaers, and Sheng Yang.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-3384
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3384: CloudStack allow VLAN range between 0-4096. Should be 
> 0-'4095'.
> 
> There're VLAN range check code in com.cloud.network.NetworkServiceImpl. 
> But it allows VLAN range between 0-4096. 
> 
> VLAN ID have 12 bit field and it's between 0-4095 (0x000 - 0xFFF) . 
> CloudStack should return error when someone try to assign VLAN ID 4096 to 
> network. 
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkServiceImpl.java 05df742 
> 
> Diff: https://reviews.apache.org/r/12278/diff/
> 
> 
> Testing
> ---
> 
> Trying to create zone with Guest VLAN range 4090-4096 from WebUI.
> 
> updatePhysicalNetwork returns error correctly.
> 
> 
> Thanks,
> 
> Toshiaki Hatano
> 
>

Re: Shared networks without IP range.

[Murali Reddy]

On 11/07/13 2:33 PM, "Prasanna Santhanam"  wrote:

>On Tue, Jul 09, 2013 at 12:27:28PM +0530, Girish Shilamkar wrote:
>> Hello,
>> 
>> In order to create shared network StartIp/endIp/gateway/netmask are
>> required. I am looking at an old test case which creates shared
>> network without IP range
>> and deploys vm in it. It of course fails as IP range is required
>> while creating shared network.
>
>> Has anything related to shared network changed in recent times or
>> the test case is just invalid ?
>
>The steps of the test are as follows. If anyone has tested this
>scenario and/or know how this works, your input would help resolve the
>failure in automated tests:

I am not aware of the history (2.2.x releases) but current behaviour is
you can not create a network without IP range being specified. For now
mark this test as invalid or make expected behaviour is to fail network
creation.

Having said that, we can create network offering and network without any
network services (including DHCP, DNS). Without IPAM/DNS/DHCP services, IP
range for the network has no relevance to CloudStack. So, in my opinion
current behaviour is not right when network offering has no services,
unless there is a reason for such enforcement. Opened CLOUDSTACK-3474 for
further investigation.
 
>
>If not, I'll remove this test as invalid.
>
># 1. create a shared network using shared network offering but do not
>specify startIp/endIp arguments
># 2. create an account
># 3. deploy a VM in this account using the above network
>
># Validate the following
># 1. listNetworks should return the created network
># 2. listAccounts to return the created account
># 3. VM deployment should succeed and NIC is in networks address space
># 4. delete the account
>
>
>-- 
>Prasanna.,
>
>
>Powered by BigRock.com
>
>

Re: CallContexts?

[Murali Reddy]

"Ipc framework and events framework needs to add this."

Alex, what specifically events framework need to handle this? Till 4.2,
UserContext was used to keep info like entity type, entity UUID, event
description etc in the UserContext. With CallContext, I see storing entity
details in CallContext is regressed, I will fix it. Let me know if there
is 
anything else to be aware.

Also, CallContext is relevant only for API triggered asyn jobs? Or context
is used for internal VMWork asyn job used by vmsync?

On 19/07/13 8:15 AM, "Alex Huang"  wrote:

>I wrote a small wiki page on what we want to do with CallContext.  Please
>have a read and comment.
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Using+CallContext
>
>--Alex
>
>
>> -Original Message-
>> From: Kelven Yang [mailto:kelven.y...@citrix.com]
>> Sent: Thursday, July 18, 2013 2:22 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: CallContexts?
>> 
>> CallContext was renamed from original UserContext. The semantic is
>>pretty
>> much the same as before to API calls
>> 
>> Kelven
>> 
>> On 7/18/13 1:25 AM, "Prasanna Santhanam"  wrote:
>> 
>> >On Thu, Jul 18, 2013 at 11:58:30AM +0530, Prasanna Santhanam wrote:
>> >> I see the following repeated lines with API calls on master code
>> >> lately: What's the call context? and what's the role?
>> >>
>> >> 2013-07-18 11:52:24,372 DEBUG [cloudstack.context.CallContext]
>> >>(RouterStatusMonitor-1:ctx-9bb138b4) Context removed
>> >>CallContext[acct=1; user=1;
>> >>session=9bb138b4-29c1-4ddf-ab47-9307a600d31e]
>> >>
>> >>  * CallContext records information about the environment the call is
>> >>made.  This
>> >>  * class must be always be available in all CloudStack code.
>> >>
>> >> Does this mean we have to do something special when creating new
>>APIs?
>> >>I'm not
>> >> quite clear from this description.
>> >>
>> >It seems from the logs that all APIs are now getting the context as
>> >user=1,account=1 (SYSTEM). Filed CLOUDSTACK-3626.
>> >
>> >
>> >
>> >--
>> >Prasanna.,
>> >
>> >
>> >Powered by BigRock.com
>> >
>
>

Re: Review Request 12752: Async commands can inject the job id

[Murali Reddy]

Ryan,

You should open a bug and add details on what the use case you are trying
to solve. Since CloudStack is not in control of UUID generation, you
should at least check that uniqueness of passed in UUID.

Also please introduce a new smoke test for 'injected job id' instead of
piggy backing the test for deploy VM.

On 19/07/13 6:02 AM, "Ryan Dietrich"  wrote:

>
>
>> On July 18, 2013, 11:34 p.m., Marcus Sorensen wrote:
>> > server/src/com/cloud/async/AsyncJobVO.java, line 141
>> > 
>>>>
>> >
>> > I'm not immediately certain why this was pulled out.
>
>Nothing is using it.  I did a scan to see if anyone is using it, and I
>didn't see anything.  Dead could should be removed, right?  Git will
>remember for us if we need it later.
>
>
>- Ryan
>
>
>---
>This is an automatically generated e-mail. To reply, visit:
>https://reviews.apache.org/r/12752/#review23457
>---
>
>
>On July 18, 2013, 11:28 p.m., Ryan Dietrich wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/12752/
>> ---
>> 
>> (Updated July 18, 2013, 11:28 p.m.)
>> 
>> 
>> Review request for cloudstack and Marcus Sorensen.
>> 
>> 
>> Repository: cloudstack-git
>> 
>> 
>> Description
>> ---
>> 
>> I added "injectedjobid" to the BaseAsyncCmd class as a parameter.
>> If set, it will allow you to tell Cloudstack what the job id instead of
>>it choosing one.
>> A basic string length test is done to verify the variable passed in is
>>actually a UUID.
>> If it is not valid, it is ignored and the job generates it's own.
>> 
>> 
>> Diffs
>> -
>> 
>>   api/src/org/apache/cloudstack/api/BaseAsyncCmd.java 0e6f95d
>>   server/src/com/cloud/api/ApiServer.java 95f17af
>>   server/src/com/cloud/async/AsyncJobVO.java 41eccb4
>>   test/integration/smoke/test_deploy_vm.py 425aeb7
>>   tools/marvin/marvin/codegenerator.py 632b8c6
>>   tools/marvin/marvin/integration/lib/base.py 161d03c
>> 
>> Diff: https://reviews.apache.org/r/12752/diff/
>> 
>> 
>> Testing
>> ---
>> 
>> Updated marvin, updated the deploy vm test.  Ran multiple async
>>commands manually, with and without injectedjobid present, no issues
>>detected.
>> 
>> 
>> Thanks,
>> 
>> Ryan Dietrich
>> 
>>
>
>

Re: [Proposal] Routing between guest networks in VLAN isolation method.

[Murali Reddy]

On 23/07/13 11:15 PM, "Nguyen Anh Tu"  wrote:

>@David: it just only add a feature for guest network mode. If a VPC has
>too
>much tiers, maybe one VPC router is not enough.

If scale is a concern with VPC router, perhaps that could be addressed. I
believe users can today deploy a routing appliance as an instance with
NIC's in both guest networks that can provide inter-vlan routing, of
course its not out-of-the box solution and needs setting up the static
routes on the instances but works. [1] has pre-VPC reference solutions for
VM connectivity across the guest networks.

[1] http://www.slideshare.net/cloudstack/cloudstack-networking

>@Ahmad: this proposal use a route instead of a nat. Vms can talk via
>privateIP. Of course, VMs in two guest networks currently can reach each
>other via hairpinNAT.
>@Chip: For the beginning, I just wanna limit privilege to Root admin. If
>users can easily config route, maybe it cause some conflict rules.
>
>
>2013/7/24 Chip Childers 
>
>> On Tue, Jul 23, 2013 at 01:26:08PM -0400, David Nalley wrote:
>> > On Tue, Jul 23, 2013 at 1:21 PM, Nguyen Anh Tu 
>> wrote:
>> > > Hi guys,
>> > >
>> > > I write a proposal about implementing routing method for guest
>>networks
>> > > using VLAN isolation. At the moment, they can reach each other due
>>to
>> > > interVLAN routing in VPC model, but can not in Guest network model.
>>So
>> the
>> > > key point is make some static routes between them, including
>>iptables
>> rules
>> > > for filtering ports and protocols. Please take a look on my
>>proposal,
>> link
>> > > below.
>> > >
>> > >
>> 
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Routing+between+Gu
>>est+networks
>> > >
>> >
>> > Isn't this exactly the case that VPC is designed to solve?
>> > What's the benefit of doing this? If we did this, would we continue
>> using VPC?
>> >
>> > --David
>> >
>>
>> Well right now, the main issue is that VPC follows the AWS VPC concepts
>> of allocating a single block for the VPC.  This isn't actually flexible
>> enough for some environments, and Nguyen's proposal is something that
>>I've
>> been looking into myself.
>>
>> Nguyen, when you state "All configurations are done by admin only.",
>> which admin?  Root?  If root only, why?
>>
>
>
>
>-- 
>
>N.g.U.y.e.N.A.n.H.t.U
>

Re: [DISCUSS] Compatibility issue between network plugins and hypervisors

[Murali Reddy]

Also, should not we treat 'isolation' as Network Element capability rather
than Hypervisor. Tunnelling capability could be a Hypervisor capability,
but isolation (STT/GRE) is Network Element capability? So,zone isolation
-> isolation provider -> supported hypervisors should be checked against
add cluster IMO.

On 26/07/13 9:24 AM, "Chiradeep Vittal" 
wrote:

>+1 (with a caveat), good idea since isolation method is supported on a
>per-zone basis.
>The caveat is that sometimes it makes sense to support multiple isolation
>methods in a zone.
>For example, VPC(advanced) + basic in the same zone.
>Why would one do this? Simply because someone might start with one
>isolation method (basic) and then offer advanced (using overlays like
>VxLAN f.e). Since templates/snapshots/volumes tend to be zone-specific,
>this makes the transition easier.
>This is not unlike AWS "EC2-classic" and "VPC" in the same zone.
>
>
>On 7/26/13 3:34 AM, "Alex Huang"  wrote:
>
>>+1
>>
>>I think we should take advantage of hypervisor capabilities to look for
>>that compatibility.
>>
>>--Alex
>>
>>> -Original Message-
>>> From: Toshiaki Hatano [mailto:toshiaki.hat...@verio.net]
>>> Sent: Thursday, July 25, 2013 3:01 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: [DISCUSS] Compatibility issue between network plugins and
>>> hypervisors
>>> 
>>> Hi devs,
>>> 
>>> 
>>> 
>>> CloudStack supports many hypervisors and many network isolation
>>>methods.
>>> 
>>> Some isolation method doesn't (or cannot) support some hypervisors,
>>> 
>>> but it looks cloudstack doesn't check compatibility between network
>>>isolation
>>> and hypervisors.
>>> 
>>> 
>>> 
>>> Why don't we check it during addCluster, first timing cloudstack-
>>> management know isolation and hypervisor, and fail if it's
>>>incompatible?
>>> 
>>> 
>>> 
>>> Best Regards,
>>> 
>>> --
>>> 
>>> Toshiaki Hatano
>>> 
>>> Verio, an NTT Communications company
>>> E-mail:  toshiaki.hat...@verio.net 
>>> 
>>> AIM:  toshiaki.hat...@verio.net 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> This email message is intended for the use of the person to whom it has
>>> been sent, and may contain information that is confidential or legally
>>> protected. If you are not the intended recipient or have received this
>>> message in error, you are not authorized to copy, distribute, or
>>>otherwise
>>> use this message or its attachments. Please notify the sender
>>>immediately by
>>> return e-mail and permanently delete this message and any attachments.
>>> Verio Inc. makes no warranty that this email is error or virus free.
>>>Thank you.
>
>

Re: Review Request 12942: CLOUDSTACK-3454: Fix test_portable_publicip

[Murali Reddy]

> On July 25, 2013, 1:28 p.m., Jenkins Cloudstack.org wrote:
> > Review 12942 failed the build test : UNSTABLE
> > The url of build cloudstack-master-with-patch #38 is : 
> > http://jenkins.cloudstack.org/job/cloudstack-master-with-patch/38/

test changes are fine. but looks like there is assumption that first IP 
associated with a network is always used for source NAT. Please open a bug, i 
will fix the issue.


- Murali


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


On July 25, 2013, 12:50 p.m., Girish Shilamkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12942/
> ---
> 
> (Updated July 25, 2013, 12:50 p.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-3454
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added isportable param to associateIP API. Fixed base class
> for PortableIP tio call portableip APIs.
> Removed test_createPortablePublicIPAcquire from basic zone run
> requires additional network creation handling which can be done
> in component tests.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_portable_publicip.py 9a3a398 
>   tools/marvin/marvin/integration/lib/base.py 0f6fdc5 
> 
> Diff: https://reviews.apache.org/r/12942/diff/
> 
> 
> Testing
> ---
> 
> Yes, but disassociating ip address fails. Maybe a product defect, yet to 
> investigate.
> 
> 
> Thanks,
> 
> Girish Shilamkar
> 
>

Re: Review Request 13061: Unable to create the Internal LB vm.

[Murali Reddy]

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

Ship it!


Branch: refs/heads/4.2
Commit: 91bf54652ec6450a58f1c44d5d67069ac99a6462

Branch: refs/heads/master
Commit: 2cca335856236aea584d69893b1adf67e5e233ad

- Murali Reddy


On July 30, 2013, 1:07 p.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13061/
> ---
> 
> (Updated July 30, 2013, 1:07 p.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk, Devdeep Singh, and Ram 
> Ganesh.
> 
> 
> Bugs: 3924
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Issue:
> ==
> Unable to created internalLB Vm. this is due while determining maxconn value 
> from networkoffering.
> to find the networking offering, networkid is passed instead of 
> networkoffering id which is causing the issue.
> 
> fixed:
> =
> fixed the issue by passing the network offering id instead of network id.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
>  76507e9 
> 
> Diff: https://reviews.apache.org/r/13061/diff/
> 
> 
> Testing
> ---
> 
> 1. was able to create the 'b' vm. internal LB VM.
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

Re: IP Address Allocation

[Murali Reddy]

On 06/08/13 8:59 AM, "Soheil Eizadi"  wrote:

>One way to achieve this behavior is to have a call out in prepareNic() to
>the NetworkElements before the call to the NetworkGuru allowing the
>NetworkElement to update the Nic Profile. In this use case the Network
>Element would suggest an IP Address. In the use case below the IP Address
>would be updated by the NetworkElement. There is logic in getIp(), the
>current IP Allocation that handles the case where the Nic Profile already
>has an IP Address. This needs to be updated to handle this new use case.
>The current use case assume that the VM had already been prepared once
>and has an IP Address allocated that could be reused.
>
>Does anyone see a problem with this approach?

Purpose of Guru (to design the network) and Element (implement the
network) are different. Right way would be for your plug-in to implement
both network Guru and element and let the guru do the IP address
allocation.

>-Soheil
>
>From: Soheil Eizadi [seiz...@infoblox.com]
>Sent: Monday, August 05, 2013 2:35 PM
>To: dev@cloudstack.apache.org
>Subject: IP Address Allocation
>
>I am trying to figure out what would be the proper way for a Plugin to
>interact with the CloudStack VM deployment and provide an authoritative
>IP Address from its database versus the local CloudStack database. It
>looks like the NetworkElements are not presented an opportunity to
>provide an IP Address and you must develop a NetworkGuru to provide this
>function. There is some customization of the IP Address designed into the
>Secondary NICs (see allocateGuestIP()).
>-Soheil
>

Re: [Discuss] Using XenServer 6.2's Clone-on-Boot feature on CloudStack

[Murali Reddy]

On 06/08/13 12:30 PM, "Nguyen Anh Tu"  wrote:

>Hi Chiradeep,
>
>Exactly Intellicache. As I know, to use this, VDIs on XenServer/XCP must
>be
>set two params:
>+ on-boot = persist (or reset). If persist, VM's data (except OS) will be
>keep when reboot. Otherwise, it will be destroy on local SR when setting
>to
>"reset".
>+ allow-caching = true. It enables cache mode on local SR.
>
>Maybe we'll add a service offering tag so AgentMgr can realize this
>option.

So there is a 'isvolatile' flag to createServiceOffering in starting from
4.2. VM's created with volatile set to true will have root disks
re-created. Perhaps You could optimise the implementation of volatile VM's
in case of Intellicache.


>Whatever we change, Xapi must set two above params for VDIs to use this
>feature. However, Intellicache seemly can't update changes to VMs which
>were booted before changing of Master image.

AFAIK, there is no solution that will update gold-image with out
recreating the VM to reflect the updates.

>
>
>2013/8/6 Chiradeep Vittal 
>
>> Is this the Intellicache feature? What changes does it require from
>> CloudStack.
>> Would just using service offering tags work?
>>
>> On 8/5/13 12:23 AM, "Nguyen Anh Tu"  wrote:
>>
>> >Hi guys,
>> >
>> >Is anyone concerned about using XenServer 6.2's clone-on-boot feature
>>on
>> >CloudStack? With it, we can quickly deploy a huge of VMs from a single
>> >golden template. This is amazing for some scenarios. For example: we
>>can
>> >allocate a special/dedicated cluster with only one golden template. And
>> >when an update or patch be applied to golden template, changes
>> >automatically apply to every VMs.
>> >
>> >Thought?
>> >
>> >Thanks,
>> >
>> >--
>> >
>> >N.g.U.y.e.N.A.n.H.t.U
>>
>>
>
>
>-- 
>
>N.g.U.y.e.N.A.n.H.t.U
>

Re: IP Address Allocation

[Murali Reddy]

nt NetworkGurus may want to share the same ip
>>address
>> allocation tables/schemes so an interface for them to share that code
>>does
>> make sense.
>> 
>> Note there's a difference between allocating ip address and the act of
>> actually issuing the ip address and associating the ip address to a
>>fqdn.  That
>> act is performed by the network elements.  Here we're specifically
>>saying
>> who is responsible for figuring out the ip address that can be
>>allocated to a
>> particular vm and works within a network.
>> 
>> --Alex
>> 
>> > -Original Message-
>> > From: Chiradeep Vittal
>> > Sent: Tuesday, August 6, 2013 11:14 AM
>> > To: dev@cloudstack.apache.org
>> > Cc: Alex Huang
>> > Subject: Re: IP Address Allocation
>> >
>> > The way the gurus are consulted for network design and reservation
>> > makes it difficult to put this inside a guru.
>> > However it does seem odd to put this inside an element. Perhaps we
>> > need a 3rd type (IpAddressReserver?)
>> >
>> >
>> > On 8/6/13 10:42 AM, "Soheil Eizadi"  wrote:
>> >
>> > >The NetworkGuru does a lot more than IP address allocation, e.g.
>> > >handle the Layer2/3 networking unique to the particular vendor. There
>> > >are a lot of NetworkElements providing their own NetworkGuru plugins
>> > >(Nicira, MidoNet, ...) extending the standard CloudStack Gurus.
>> > >
>> > >The feature of providing IP Address Allocation, DHCP and DNS is
>> > >common for all these networks, so rather than provide our own Guru
>> > >the proposed design would allow the above functions to coexist with
>> > >existing
>> > Gurus.
>> > >
>> > >-Soheil
>> > >
>> > >From: Murali Reddy [murali.re...@citrix.com]
>> > >Sent: Tuesday, August 06, 2013 3:24 AM
>> > >To: dev@cloudstack.apache.org
>> > >Subject: Re: IP Address Allocation
>> > >
>> > >On 06/08/13 8:59 AM, "Soheil Eizadi"  wrote:
>> > >
>> > >>One way to achieve this behavior is to have a call out in
>> > >>prepareNic() to the NetworkElements before the call to the
>> > >>NetworkGuru allowing the NetworkElement to update the Nic Profile.
>> > >>In this use case the Network Element would suggest an IP Address. In
>> > >>the use case below the IP Address would be updated by the
>> > >>NetworkElement. There is logic in getIp(), the current IP Allocation
>> > >>that handles the case where the Nic Profile already has an IP
>> > >>Address. This needs to be updated to handle this
>> > new use case.
>> > >>The current use case assume that the VM had already been prepared
>> > once
>> > >>and has an IP Address allocated that could be reused.
>> > >>
>> > >>Does anyone see a problem with this approach?
>> > >
>> > >Purpose of Guru (to design the network) and Element (implement the
>> > >network) are different. Right way would be for your plug-in to
>> > >implement both network Guru and element and let the guru do the IP
>> > >address allocation.
>> > >
>> > >>-Soheil
>> > >>
>> > >>From: Soheil Eizadi [seiz...@infoblox.com]
>> > >>Sent: Monday, August 05, 2013 2:35 PM
>> > >>To: dev@cloudstack.apache.org
>> > >>Subject: IP Address Allocation
>> > >>
>> > >>I am trying to figure out what would be the proper way for a Plugin
>> > >>to interact with the CloudStack VM deployment and provide an
>> > >>authoritative IP Address from its database versus the local
>> > >>CloudStack database. It looks like the NetworkElements are not
>> > >>presented an opportunity to provide an IP Address and you must
>> > >>develop a NetworkGuru to provide this function. There is some
>> > >>customization of the IP Address designed into the Secondary NICs
>>(see
>> allocateGuestIP()).
>> > >>-Soheil
>> > >>
>> > >
>> > >
>
>

Re: Review Request 13534: Autoscaling: Deleting an isolated network of an account deletes also the autoscaling rule for a network associated with another account

[Murali Reddy]

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

Ship it!


master 5cd8edd44353c756eeb6d05caaf17ed713d37f7a
4.27281593758df4b5d5d110507965d3468bfd2bff4

- Murali Reddy


On Aug. 13, 2013, 10:23 a.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13534/
> ---
> 
> (Updated Aug. 13, 2013, 10:23 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh, Murali Reddy, Ram Ganesh, and 
> Vijay Venkatachalam.
> 
> 
> Bugs: CLOUDSTACK-3369
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> issue:
> if  autoscale policies are created by CS , then when any network gets deleted 
> which got created with Netscaler as LB provider, the autoscale servers are 
> getting deleted.
> 
> during delete the network ipassoc cmd executed on Netscaler resouce is 
> cleaning up the services which are present in the same subnet. 
> NetUtils.sameSubnet(vlanSelfIp, server.get_ipaddress(), vlanNetmask) is 
> returning true for the autoscale servers even they are not present in the 
> subnet because this method is returning true if any any of the ip is true.
> 
> autoscale server don't have ip address, so true is returned and hence 
> removing the autoscale servers. which is causing severe issue for the 
> autoscale policies created in cloudstack.
> 
> Fix:
> 
> 
> while executing the method deleteServersInGuestVlan which will clean up the 
> servers present in same subnet, check is made not to delete the autoscale 
> servers.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  e42a9ea 
> 
> Diff: https://reviews.apache.org/r/13534/diff/
> 
> 
> Testing
> ---
> 
> created accounts testa testb and created networks with NS as LB provider 
> network offering.
> 
> 1. In TestA, created autoscale policy and wait for deploy the instance. 
> policy got created and vm got deployed.
> 2. Delete the testB network, check in ns.log that autoscale servers won't get 
> delete.
> 3. in testB network, create LB rules, and delete the network, verified 
> autoscale servers won't get delete.
> 4. Destroy testA, TestB network, first rules got cleaned up and then the ip 
> assocations of the network are removed.
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

Re: Review Request 13615: [Autoscale] Account deletion doesn't delete all autoscaled LB rules created by the account

[Murali Reddy]

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

Ship it!


4.2 a03c5f5b1bb3e45b5b2a8365b0c09d48778e426a
master bb26b854fb89ef71c5183e2c23ef17898d9d

- Murali Reddy


On Aug. 16, 2013, 12:39 p.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13615/
> ---
> 
> (Updated Aug. 16, 2013, 12:39 p.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Ram Ganesh.
> 
> 
> Bugs: CLOUDSTACK-4237
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Issue:
> for an account if there are multiple LB rules and Autoscale Policies, when 
> Account is deleted. All the LBrules, Autoscale polices are not getting delete 
> in Netscaler resource. But in CS db they are getting cleared.
> 
> Root Cause:
> ===
> while processing the LBConfigcmd in NSResource, after processing the first 
> Autoscale cmd, no other rules are getting processed as its returning from 
> loop.
> 
> Fix:
>  
> 
> Fixed the issue to process all the autoscale config rules in the 
> LBConfigCommand.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  4020059 
> 
> Diff: https://reviews.apache.org/r/13615/diff/
> 
> 
> Testing
> ---
> 
> 1. created a testA account and created network with NS as LB provider and 
> Acquired 3 ip's
> 2. on each IP configured multiple Autoscale polices and normal LB rules.
> 3. Verified on NS there are total 4 vservers and 3 services ( 2 autoscale and 
> 2 cloud service)
> 4. deleted one LB rule. LB rule got delete successfully and the same is 
> removed from NS.
> 5. deleted the account, network got deleted as part of it all the rules got 
> revoked and sent to NSResource to execute them. 
> All the servers, lb vservers got remove successfully.
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

Re: Source NAT not applied on network startup (See Jira CLOUDSTACK-234)

[Murali Reddy]

I made a commit in 4.2-forward, will wait for BVT to run before raising a
pull request to 4.2.

On 22/08/13 12:12 PM, "Dave Cahill"  wrote:

>Adding Chiradeep for guidance, as Murali seems to be away at the moment.
>
>Prasanna kindly verified that this is an issue with Virtual Router as well
>as MidoNet, so I have filed a bug against 4.2:
>https://issues.apache.org/jira/browse/CLOUDSTACK-4442
>
>
>
>On Thu, Aug 22, 2013 at 12:10 PM, Dave Cahill 
>wrote:
>
>> Also, I tried to find the code review for this change, but couldn't
>>track
>> it down - could someone point me to it?
>>
>>
>> On Thu, Aug 22, 2013 at 10:26 AM, Dave Cahill
>>wrote:
>>
>>> Hi Murali,
>>>
>>> After this change [1], how do Source NAT IPs get applied to a network
>>>on
>>> network startup / first VM launch?
>>>
>>> Previously, applyIpAssociations would get called as part of
>>> reprogramNetworkRules, but this change introduces what it calls "a lazy
>>> approach". From what I can see, this means that source NAT doesn't
>>>work on
>>> startup, and I need to add a Static NAT or some other rule in order to
>>>wake
>>> up the lazy approach and have the Source NAT + the new rule be applied.
>>>
>>> Is there a workaround I'm missing? Maybe it's necessary to also enable
>>> the firewall service to trigger application of the source NAT rules?
>>>
>>> Thanks,
>>> Dave.
>>>
>>> [1]
>>> 
>>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=se
>>>rver/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6
>>>102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe5
>>>68fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
>>>
>>> On Tue, Jul 9, 2013 at 5:47 PM, Murali Reddy (JIRA)
>>>wrote:
>>>
>>>>
>>>>  [
>>>> 
>>>>https://issues.apache.org/jira/browse/CLOUDSTACK-234?page=com.atlassian
>>>>.jira.plugin.system.issuetabpanels:all-tabpanel]
>>>>
>>>> Murali Reddy resolved CLOUDSTACK-234.
>>>> -
>>>>
>>>> Resolution: Fixed
>>>>
>>>> > create/delete firewa/lb/pf rule: send ip assoc command only on first
>>>> rule is created on the IP and last rule is revoked on the IP
>>>> >
>>>> 
>>>>---
>>>>--
>>>> >
>>>> > Key: CLOUDSTACK-234
>>>> > URL:
>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-234
>>>> > Project: CloudStack
>>>> >  Issue Type: Bug
>>>> >  Security Level: Public(Anyone can view this level - this is the
>>>> default.)
>>>> >  Components: Management Server
>>>> >Affects Versions: 4.0.0
>>>> >Reporter: Alena Prokharchyk
>>>> >Assignee: Murali Reddy
>>>> > Fix For: 4.2.0
>>>> >
>>>> >
>>>> > We have to improve the logic for creating/deleting any kind of
>>>> firewall rules. At the moment ipAssoc is being called when:
>>>> > * the first rule for the ip address is being created
>>>> > * the last rule for the IP address is being removed
>>>> > As a part of ipAssoc command, we send all ip addresses assigned to
>>>>the
>>>> guest network of the rule. The behavior has to be fixed the way we
>>>>send ip
>>>> assoc only for the ip address the rule is being created for.
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> If you think it was sent incorrectly, please contact your JIRA
>>>> administrators
>>>> For more information on JIRA, see:
>>>> http://www.atlassian.com/software/jira
>>>>
>>>
>>>
>>
>

Re: [PROPOSAL] EIP across zones

[Murali Reddy]

On 21/03/13 3:10 AM, "Manan Shah"  wrote:

>Thanks Murali for the FS. Below are some questions/comments.
>
>1. Is there a reason why we wouldn't support this feature for VPC?

Manan, thanks for reviewing. There is no particular reason, VPC would need
little different semantics we need to think through. Its just that I do
not have bandwidth to get the support in VPC as well for 4.2. I would
rather get the EIP support in 'advanced zone' and across regions baked up
properly for 4.2.

>2. Your FS talks about supporting EIP for Shared Networks as well. Are you
>going to support that? If so, are you going to support it only when NS is
>enabled as a LB service provider?

Yes, We already support NetScaler as EIP & ELB service provider in basic
zone 'shared network'. So I would imagine this would be easy extension.

>3. On Stopping a VM in basic zone today, CS does not detach the EIP from
>the VM. I believe the functionality should be consistent with the current
>support as well as consistent across Basic and Advanced Zones
>4. In Advanced Zone Network with EIP service, I am assuming you will not
>allocate a Public IP for every guest VM. Your FS talks about Advanced Zone
>behaving exactly like Basic Zone. That's why I am asking.
>5. Currently, we support EIP in Basic Zone. For basic zone users, it might
>get confusing that there are two ways to do EIP in Basic Zone.

Ok, I missed this point. I will keep the backward compatibility and keep
the semantics of EIP in advanced zone same with basic zone. I will update
the spec to reflect this.

Thanks,
Murali 

Re: Cloudstack git repositories

[Murali Reddy]

On 21/03/13 12:39 PM, "Sateesh Chodapuneedi"
 wrote:

>Unable to access Cloudstack git repositories.
>Seems infra is migrating our git repos off incubator.
>
>Regards,
>Sateesh
>

Change the .git config to refer
"git-wip-us.apache.org/repos/asf/cloudstack.git"

Review Request: CLOUDSTACK-1368: Shared network - Not able to delete network because of java.lang.NullPointerException.

[Murali Reddy]

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

Review request for cloudstack and Chip Childers.


Description
---

Patch for 4.1 blocker "CLOUDSTACK-1368: Shared network - Not able to delete 
network because of java.lang.NullPointerException."


This addresses bugs -, CLOUDSTACK-1368:, Not, Shared, able, because, delete, 
java.lang.NullPointerException., network, network, of, and to.


Diffs
-

  api/src/com/cloud/network/Network.java 2bf7b7f 

Diff: https://reviews.apache.org/r/10061/diff/


Testing
---

Tested life cycle of both isolated and shared networks


Thanks,

Murali Reddy

Re: [PROPOSAL] EIP across zones

[Murali Reddy]

On 21/03/13 11:21 PM, "Manan Shah"  wrote:

>Thanks Murali for your prompt response. For the VPC part, can you explain
>what is the difference between supporting on Isolated Network and
>supporting on VPC? I would assume they should be very similar. May be I am
>mistaken here.

May be, I have not thought through or explored AWS VPC EIP semantics. Can
you please explore and see the support for isolated network can work for
VPC as well semantically? We can raise feature request for next release.

>
>Regards,
>Manan Shah
>
>
>
>
>On 3/20/13 11:52 PM, "Murali Reddy"  wrote:
>
>>On 21/03/13 3:10 AM, "Manan Shah"  wrote:
>>
>>>Thanks Murali for the FS. Below are some questions/comments.
>>>
>>>1. Is there a reason why we wouldn't support this feature for VPC?
>>
>>Manan, thanks for reviewing. There is no particular reason, VPC would
>>need
>>little different semantics we need to think through. Its just that I do
>>not have bandwidth to get the support in VPC as well for 4.2. I would
>>rather get the EIP support in 'advanced zone' and across regions baked up
>>properly for 4.2.
>>
>>>2. Your FS talks about supporting EIP for Shared Networks as well. Are
>>>you
>>>going to support that? If so, are you going to support it only when NS
>>>is
>>>enabled as a LB service provider?
>>
>>Yes, We already support NetScaler as EIP & ELB service provider in basic
>>zone 'shared network'. So I would imagine this would be easy extension.
>>
>>>3. On Stopping a VM in basic zone today, CS does not detach the EIP from
>>>the VM. I believe the functionality should be consistent with the
>>>current
>>>support as well as consistent across Basic and Advanced Zones
>>>4. In Advanced Zone Network with EIP service, I am assuming you will not
>>>allocate a Public IP for every guest VM. Your FS talks about Advanced
>>>Zone
>>>behaving exactly like Basic Zone. That's why I am asking.
>>>5. Currently, we support EIP in Basic Zone. For basic zone users, it
>>>might
>>>get confusing that there are two ways to do EIP in Basic Zone.
>>
>>Ok, I missed this point. I will keep the backward compatibility and keep
>>the semantics of EIP in advanced zone same with basic zone. I will update
>>the spec to reflect this.
>>
>>Thanks,
>>Murali 
>>
>
>

Re: [PROPOSAL] EIP across zones

[Murali Reddy]

On 22/03/13 3:26 AM, "Chiradeep Vittal" 
wrote:

>
>
>On 3/20/13 8:31 PM, "Murali Reddy"  wrote:
>>>are outside of our control scares me.
>>
>>David, yes this is a valid concern. So, initially I was planning to
>>leverage the ADC like NetScaler's routing capabilities to advertise
>>routes. When IP is transferred from zone to another zone, CloudStack will
>>orchestrate the route advertisements. But as you reasoned, this is not
>>the
>>best way to go. So what I am proposing is that, let CloudStack raise the
>>trigger (raise action event for eg.) when IP is transferred, on which
>>Admin/external tools can act up on.
>
>The document says "leverage Netscaler". I think the value of this is moot
>for someone not already using a Netscaler?

Sorry, I don't see any reference to leveraging NetScaler in FS for route
advertisement. I have put explicit assumption "It is assumed that when an
EIP is transferred from one zone to another, it is expected that admin
performs out-of-band operation that will ensure that traffic for EIP is
routed to the new zone." Also a requirement "Support for NetScaler as EIP
service provider but the design should be generic so any NAT provider can
be enhanced to act of EIP service provider". Since the proposal is only to
extend the NetScaler plug-in as EIP service provider, so value is only for
those already using NetScaler as of now. But one can extend VR or other
supported network appliances to be EIP service provider as well.

>
>>
>>>
>>>What exactly are we getting here that we couldn't obtain with things
>>>like having folks manage DNS much better, as I fear there are many
>>>dragons along this path.
>>
>>Good question. This is purely in-practice AWS EIP use case. With DNS
>>re-mapping there is huge failover recovery time (propagation of new DNS
>>mapping, client cache etc) in reflecting the DNS name to new public IP.
>>What is happening in this case is DNS name, public IP remain static, it
>>just the back end server that changes.
>>
>>I don¹t see testing is big concern. In some sense CloudStack is dumb in
>>this context all its doing is just configuring NAT rule, intelligence to
>>advertise the IP or out side of CloudStack.
>
>Except for Netscaler? Should we leave this out for the same reason?

Not sure I get the question correctly. As mentioned above advertisement
has to be out-of-band, could be NetScaler or edge routers that is will
advertising the IP availability.

Re: [PROPOSAL] EIP across zones

[Murali Reddy]

On 22/03/13 9:37 AM, "Manan Shah"  wrote:

>My assumption is that EIP for VPC should work exactly the same as EIP for
>Isolated Networks since EIP is like another Public IP except that it can
>be moved across zones. Also, we do support static NAT in VPC as well as
>Isolated. So, my thinking is that it might just work with minimal effort.

It might not just work. I can think of questions like, can I move the EIP
across the tiers in VPC? Since cloudStack can not have tier's of VPC in
multiple zones, question of moving across zones does not arise? Does EIP
service provider and 'public gateway' need to be same? Does network ACL's
has any impact? Etc.

It would take significant time to think through the scenarios, tweak the
existing VPC functionality to adapt to EIP, write unit test, marvin test.
Also QA effort for EIP in isolated network won't be same for VPC.

>
>Regards,
>Manan Shah

[ACS41] [PATCH REQUEST] CLOUDSTACK-1804 Upgrade 4.0 -> 4.1 - DB upgrade fails.

[Murali Reddy]

Chip, please pull in this commit in master to 4.1 branch.

commit f414b8a850607d20c0a78d455b4c43d90947b41f
Author: Murali Reddy 
Date:   Wed Mar 27 18:06:22 2013 +0530

CLOUDSTACK-1804:Upgrade 4.0 -> 4.1 - DB upgrade fails.

remove the data migration functions that were accidently introduced by
commit b6727e564654da2604e17ca477e21d03d4afeb05

Re: [MERGE] GSLB

[Murali Reddy]

On 20/03/13 7:15 AM, "Murali Reddy"  wrote:

>I would like to merge GSLB feature proposed [1] and developed in the
>feature branch [2] into master. Code for this feature pretty much
>conforms to what was proposed in FS [3]. I added unit tests for all the
>new service layer methods introduced[4]. I have made the patch available
>at [5], if any one wish to review please do so.
>
>This functionality is completely isolated and code path is not hit unless
>GSLB functionality is used.
>
>[1] 
>http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201301.m
>box/%3ccd1281ee.2b118%25murali.re...@citrix.com%3E
>[2] 
>https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=short
>log;h=refs/heads/gslb-wip
>[3] 
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSLB+(Global+Server
>+Load+Balancing)+Functional+specification+and+Design+Document
>[4] 
>https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob;
>f=server/test/org/apache/cloudstack/region/gslb/GlobalLoadBalancingRulesSe
>rviceImplTest.java;h=cea4fd9324b232ad2de92954b9693e2fc6ac4bc1;hb=refs/head
>s/gslb-wip
>[5] https://reviews.apache.org/r/10021/
>
>-Murali
>
>

I merged this feature into master with below commit. All review comments
were addressed except one, I will open a bug for it.

commit c5fb8349bf92b48bca6d06370112f5ec04a9d098
Author: Murali Reddy 
Date:   Wed Mar 27 17:54:07 2013 +0530

CLOUDSTACK-653 : High Availability: implement GSLB (Global Server Load
Balancing) capability for ELB service merging GSLB feature

Re: [MERGE] GSLB

[murali reddy]

On Wed, Mar 27, 2013 at 7:26 PM, Chip Childers wrote:

> On Wed, Mar 27, 2013 at 01:08:58PM +0000, Murali Reddy wrote:
> > On 20/03/13 7:15 AM, "Murali Reddy"  wrote:
> >
> > I merged this feature into master with below commit. All review comments
> > were addressed except one, I will open a bug for it.
>
> Which comment?
>
>
This comment "It will be good to have the zone names (site info) be listed
as part of the ListGSLB" from Vijay [1].

[1] https://reviews.apache.org/r/10021/

Re: [ACS41] Release Status - Bugs to kill!

[Murali Reddy]

On 27/03/13 8:04 PM, "Chip Childers"  wrote:

>
>Murali Reddy -
>  CLOUDSTACK-1673 AWS Regions - Events - User disable event does not
>include the UUID of the user that was disabled.
>
>  Murali, you mentioned that you were working on a fix for this.  You
>  happened to note that you would have it by the 20th.  Having any luck?


Sorry on the delay. Though I have fix ready, I can not fully test it
because most of the events are not generated due to bug CLOUDSTACK-1664.
Moreover I do not think its critical bug. I have left below comment in the
bug and marked as major. I can fix this bug if required only after fix for
CLOUDSTACK-1664 is checked-in.

"Do not think its critical issue in the context of Regions. While syncing
account/user/domain information across the regions using event bus is just
one implementation option. User provisioning system's like portals can
directly create account/user/domains across regions with out need of event
bus.

Even if one uses event bus, there are other implementation options with
which once achieve this. For eg, when User/Account/Domain create event
occurs, consumers can query list of account/domain/accounts details in the
region which generated the event and figure the details of new object
created."

>
>
>-chip
>

Re: Jetty Failing on latest master due to class UCS manager not Found

[Murali Reddy]

On 28/03/13 7:42 AM, "Chip Childers"  wrote:

>On Wed, Mar 27, 2013 at 04:31:05PM -0700, Kelven Yang wrote:
>> For UCS issue, I've put a fix in.
>> 
>> For GSLB, a work around is to run non-OSS build, hopefully this can
>>unlock
>> developers temporarily on master branch
>
>Good work-around for now.
>
>Murali - This appears to be something that we *all* missed realizing
>prior to the merge of the GSLB functionality.  Can you sort this out
>during your day today?

I was running Non-oss builds, so could not hit this issue. My apologies
for the breaking OSS build.

Kelven,

I am not sure how to fix this issue. If there is no implementing class,
why should inject fail? I was under impression it will be set to null?

I have this code in one of the managers in server, but the implementing
class for GslbServiceProvider is only present in non-oss NetScaler
plug-in. If you can suggest how to deal with this in Spring auto wiring
that would be useful for me to quickly fix this.

@Inject
protected GslbServiceProvider _gslbProvider;

Re: Jetty Failing on latest master due to class UCS manager not Found

[Murali Reddy]

On 28/03/13 9:00 AM, "Kelven Yang"  wrote:
>>
>>I was running Non-oss builds, so could not hit this issue. My apologies
>>for the breaking OSS build.
>>
>>Kelven,
>>
>>I am not sure how to fix this issue. If there is no implementing class,
>>why should inject fail? I was under impression it will be set to null?
>>
>>I have this code in one of the managers in server, but the implementing
>>class for GslbServiceProvider is only present in non-oss NetScaler
>>plug-in. If you can suggest how to deal with this in Spring auto wiring
>>that would be useful for me to quickly fix this.
>>
>>@Inject
>>protected GslbServiceProvider _gslbProvider;
>>
>
>In this case, you should avoid using auto-wiring, so that it won't be
>bound at loading time. Spring is designed to shout out loudly at loading
>time instead of run-time if it finds any unresolvable auto-wiring in
>place. It is good to expose the issue early and force developer to fix it.
>
>This is what you may do,
>
>1) Remove @Inject for _gslbProvider;
>2) Make your code be safe at runtime to deal with the possibility that
>_gslbProvider is null
>3) Provide getter and setters to _gslbProvider
>4) Put the wiring logic in nonossComponentContext.xml so that it is only
>loaded in non-OSS build
>
>Kelven

Thanks Kelven. Temporarily I pushed
e8a144a21d46467109ae2780fe30cc1e34b0abcf to master that bypass auto
wiring. This will unblock the OSS builds.

I will apply clean fix based on what you suggested.

Re: Jetty Failing on latest master due to class UCS manager not Found

[Murali Reddy]

On 28/03/13 9:00 AM, "Rajesh Battala"  wrote:

>Jetty is failing to start on latest master building oss.
>Am on the latest master, building oss and starting jetty is failing with
>below error. 
>
>Error creating bean with name 'globalLoadBalancingRulesServiceImpl':
>Injection of autowired dependencies failed; nested exception is
>org.springframewor
>  k.beans.factory.BeanCreationException: Could not autowire field:
>protected org.apache.cloudstack.region.
>   gslb.GslbServiceProvider
>org.apache.cloudstack.region.gslb.GlobalLoadBalancingRulesServiceImpl._gsl
>bProv  ider;
>nested exception is
>org.springframework.beans.factory.NoSuchBeanDefinitionException: No
>matching b  ean
>of type [org.apache.cloudstack.region.gslb.GslbServiceProvider] found for
>dependency: expected at le
>  ast 1 bean which qualifies as autowire candidate for this
>dependency. Dependency annotations: {@javax.in
>  ject.Inject()}
>at 
>org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostPr
>ocessor.postProcess
>   PropertyValues(AutowiredAnnotationBeanPostProcessor.java:287)
>at org.springframe

Please pull latest master, I pushed a fix.

Re: [ACS41] Release Status - Bugs to kill!

[Murali Reddy]

On 27/03/13 9:49 PM, "Chip Childers"  wrote:

>On Wed, Mar 27, 2013 at 03:39:25PM +, Murali Reddy wrote:
>> On 27/03/13 8:04 PM, "Chip Childers"  wrote:
>> 
>> >
>> >Murali Reddy -
>> >  CLOUDSTACK-1673 AWS Regions - Events - User disable event does not
>> >include the UUID of the user that was disabled.
>> >
>> >  Murali, you mentioned that you were working on a fix for this.  You
>> >  happened to note that you would have it by the 20th.  Having any
>>luck?
>> 
>> 
>> Sorry on the delay. Though I have fix ready, I can not fully test it
>> because most of the events are not generated due to bug CLOUDSTACK-1664.
>> Moreover I do not think its critical bug. I have left below comment in
>>the
>> bug and marked as major. I can fix this bug if required only after fix
>>for
>> CLOUDSTACK-1664 is checked-in.
>> 
>> "Do not think its critical issue in the context of Regions. While
>>syncing
>> account/user/domain information across the regions using event bus is
>>just
>> one implementation option. User provisioning system's like portals can
>> directly create account/user/domains across regions with out need of
>>event
>> bus.
>> 
>> Even if one uses event bus, there are other implementation options with
>> which once achieve this. For eg, when User/Account/Domain create event
>> occurs, consumers can query list of account/domain/accounts details in
>>the
>> region which generated the event and figure the details of new object
>> created."
>> 
>
>Thanks for the reply.  Assuming that Kelvin's patch for 1664 is actually
>in the
>set of fixes I already applied to 4.1, does that mean that you can test
>and resolve 1673 now?  I see your point about this not being the only
>implementation model for regions, but it is the one that's being
>included as the reference approach for 4.1.  Not syncing a disable event
>sounds like a potential security hole.
>
>Unless anyone objects, and based on the logic above, I'd still consider
>1673 as a critical fix for 4.1.
>
>-chip
>

Ok, I can fix bug 1673 for 4.1 but I do not see any security issue with
1673. There bug is about the events published on the event bus, does not
have specific information (UUID) on which user/account action is taken.
Did you mean issue reported in 1664 is security issue? There are no events
generated at all by CloudStack for account enable etc.

On 1673, I wasted some time testing this issue on master, looks like
changes for CLOUDSTACK-1664 are not in master yet. I will test with 4.1,
and see if I can close this bug by EOD today.

Re: [DISCUSS] Palo Alto Integration

[Murali Reddy]

On 28/03/13 10:59 PM, "Will Stevens"  wrote:

>I am trying to implement the non-overlapping cidrs right now and I have
>some questions.  Does the ExternalGuestNetworkGuru create networks with
>non-overlapping cidrs by default?  Or do I need to override it's 'design'
>and 'implement' methods to implement non overlapping cidrs?

Will, yes, it does by default. You can just use
'ExternalGuestNetworkGuru'. Just so that you know, there is check
'networkIsConfiguredForExternalNetworking' in ExternalGuestNetworkGuru.
Which basically checks if provider is configured as service provider using
external physical appliances. So when you declare provider, mark
'isExternal' as true in the provider constructor.

>
>If I have to write my own methods, I think I understand how to
>override ExternalGuestNetworkGuru and then get it to run by adding it to
>the components.xml (or nonoss-components.xml) as well as the
>componentContext.xml.in.
>
>If I do not have to actually write the logic for the non-overlapping cidrs
>(which i am hoping is the case), and the ExternalGuestNetworkGuru actually
>implements that logic, how would I get the ExternalGuestNetworkGuru into
>my
>flow without actually overriding the class?  I understand that the
>components are loaded through the components.xml stuff, but its not clear
>how you specify which NetworkGuru should be used in my specific flow.
>
>I am basically working from this
>documentng.html>and
>the code.  Is there any other resources I should be aware of for
>extending the CloudStack networking functionality?
>
>I have a good start on a Resource, ExternalFirewallElement and an
>ExternalFirewallService.  I can currently set the Palo Alto as the
>provider
>of Firewall, SourceNat, StaticNat and Port Forwarding services.  I can
>currently Add, List, Configure and Delete my Palo Alto provider.
>
>I am getting there, but I still feel like there are gaps in my knowledge
>when using the CS networking plugin functionality.

Good the hear the progress. Feel free to ask any question.

Thanks,
Murali

>
>Thanks,
>
>Will

Re: [PROPOSAL] EIP across zones

[Murali Reddy]

On 26/03/13 8:10 PM, "Adam Grochowski"  wrote:

>Hi,
>So I'm curious - what is the proposed method to move a single IP
>across zones (presuming these zones span regions).  As Chiradeep
>mentioned earlier, /24 is the largest block that will be advertised,
>so it would necessitate moving (or advertising in two locations, and
>back hauling back to one)  an entire class C to accomplish this (or
>some black magic like LISP).

Adam, there is no proposed method to move IP across the zones. Having a
native capability in CloudStack to move IP across the zones does not make
sense. We will be just assuming CloudStack will have control to many
infrastructure components (orchestrate route advertisements etc). Instead
what is being proposed is, let the CloudStack raise an event when user
moves IP across the zones, then let admin act up on the event and initiate
the IP availability from new zone. There is no assumption or proposed
method when and how admin to achieve this. Operator can opt for any
solution that works in distributed data centre setup.

>
>My other question revolves around the actual usefulness of EIP across
>regions, and whether or not the problem can be solved simply with DNS
>changes / global load balancing.

DNS/GSLB is a alternative solution that works in active-active setups. But
the EIP is suited in active-standby setups. Please see my response to
David's question about the usefulness of EIP[1]

[1] http://markmail.org/message/eu2hby4gruf67frb

>
>On Fri, Mar 22, 2013 at 4:34 AM, Murali Reddy 
>wrote:
>> On 22/03/13 9:37 AM, "Manan Shah"  wrote:
>>
>>>My assumption is that EIP for VPC should work exactly the same as EIP
>>>for
>>>Isolated Networks since EIP is like another Public IP except that it can
>>>be moved across zones. Also, we do support static NAT in VPC as well as
>>>Isolated. So, my thinking is that it might just work with minimal
>>>effort.
>>
>> It might not just work. I can think of questions like, can I move the
>>EIP
>> across the tiers in VPC? Since cloudStack can not have tier's of VPC in
>> multiple zones, question of moving across zones does not arise? Does EIP
>> service provider and 'public gateway' need to be same? Does network
>>ACL's
>> has any impact? Etc.
>>
>> It would take significant time to think through the scenarios, tweak the
>> existing VPC functionality to adapt to EIP, write unit test, marvin
>>test.
>> Also QA effort for EIP in isolated network won't be same for VPC.
>>
>>>
>>>Regards,
>>>Manan Shah
>>
>>
>>
>
>
>
>-- 
>Adam Grochowski ** SunGard Availability Services ** 401 N. Broad
>Street - Mezzanine ** Philadelphia, PA 19108 ** 215-446-2679 **
>adam.grochow...@sungard.com
>

[ACS41][Patch Request]

[Murali Reddy]

commit 48311363d600264cb3542992a615706cb92f90ad
Author: Murali Reddy 
Date:   Fri Mar 29 15:53:21 2013 +0530

CLOUDSTACK-1834: Events are not generated for registerUserKeys(),
Enabling account and Editing account.

Re: Jetty Failing on latest master due to class UCS manager not Found

[Murali Reddy]

On 29/03/13 12:45 AM, "Chiradeep Vittal" 
wrote:

>For optional dependencies, JSR330 injection requires using setter
>injection.
>You should write
>
>@Inject void setGslbProvider(GslbProvider provider) {
>  this._gslbProvider = provider;
>}

Thanks Chiradeep for suggestion. But due to Spring default behaviour with
@Inject, both setter and interface injection fails if there is no
implementation. 

For now, I am just initializing through the bean property configured in
componentContext.xml and nonossComponentContext.xml.

>
>
>
>On 3/27/13 8:36 PM, "Murali Reddy"  wrote:
>
>>On 28/03/13 9:00 AM, "Rajesh Battala"  wrote:
>>
>>>Jetty is failing to start on latest master building oss.
>>>Am on the latest master, building oss and starting jetty is failing with
>>>below error. 
>>>
>>>Error creating bean with name 'globalLoadBalancingRulesServiceImpl':
>>>Injection of autowired dependencies failed; nested exception is
>>>org.springframewor
>>>  k.beans.factory.BeanCreationException: Could not autowire field:
>>>protected org.apache.cloudstack.region.
>>>   gslb.GslbServiceProvider
>>>org.apache.cloudstack.region.gslb.GlobalLoadBalancingRulesServiceImpl._g
>>>s
>>>l
>>>bProv  ider;
>>>nested exception is
>>>org.springframework.beans.factory.NoSuchBeanDefinitionException: No
>>>matching b  ean
>>>of type [org.apache.cloudstack.region.gslb.GslbServiceProvider] found
>>>for
>>>dependency: expected at le
>>>  ast 1 bean which qualifies as autowire candidate for this
>>>dependency. Dependency annotations: {@javax.in
>>>  ject.Inject()}
>>>at 
>>>org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPost
>>>P
>>>r
>>>ocessor.postProcess
>>>   PropertyValues(AutowiredAnnotationBeanPostProcessor.java:287)
>>>at org.springframe
>>
>>Please pull latest master, I pushed a fix.
>>
>
>

Re: Review Request: Mulitiple ip address per nic support for advacned shared networks

[Murali Reddy]

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



server/src/com/cloud/network/NetworkServiceImpl.java
<https://reviews.apache.org/r/10040/#comment38794>

this check not required



server/src/com/cloud/network/NetworkServiceImpl.java
<https://reviews.apache.org/r/10040/#comment38795>

Same here.this check not required


- Murali Reddy


On March 21, 2013, 3:58 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10040/
> ---
> 
> (Updated March 21, 2013, 3:58 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Murali Reddy, and anthony 
> xu.
> 
> 
> Description
> ---
> 
> Changes added for supporting multiple ip address per nic for shared networks
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkServiceImpl.java 8303b0b 
> 
> Diff: https://reviews.apache.org/r/10040/diff/
> 
> 
> Testing
> ---
> 
> 1. Tested adding and removing the ip for nic using the APIs
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request: BigSwitch networking plugin update

[Murali Reddy]

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

Ship it!


Branch: refs/heads/master
Commit: ee3fd1843533528eb3872951730fee6e5802c348
Parents: 690c312
Author: Kanzhe Jiang 
Authored: Fri Mar 29 18:48:50 2013 +0530
Committer: Murali Reddy 
Committed: Fri Mar 29 18:54:48 2013 +0530

- Murali Reddy


On March 29, 2013, 6:38 a.m., Kanzhe Jiang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9789/
> ---
> 
> (Updated March 29, 2013, 6:38 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> Update BigSwitch Plugin:
> . UI support for adding BigSwitch controller as a network service provider
> . Correct the message format between the plugin and the controller
> . Add Health check API
> 
> 
> This addresses bug 733.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties d167a5c 
>   client/tomcatconf/componentContext.xml.in 23566e2 
>   client/tomcatconf/nonossComponentContext.xml.in 20e0c32 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/api/commands/DeleteBigSwitchVnsDeviceCmd.java
>  f26bdde 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/api/commands/ListBigSwitchVnsDevicesCmd.java
>  002d750 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/api/response/BigSwitchVnsDeviceResponse.java
>  ede5adf 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/BigSwitchVnsDeviceVO.java
>  7e64833 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/Attachment.java
>  9a13467 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/AttachmentData.java
>  PRE-CREATION 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/BigSwitchVnsApi.java
>  c409dce 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/ControlClusterStatus.java
>  9181afd 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/Network.java
>  c89c693 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/NetworkData.java
>  PRE-CREATION 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/Port.java
>  bf749d0 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/PortData.java
>  PRE-CREATION 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/element/BigSwitchVnsElement.java
>  95c9e18 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/guru/BigSwitchVnsGuestNetworkGuru.java
>  b96ea56 
>   
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/resource/BigSwitchVnsResource.java
>  8d070b5 
>   
> plugins/network-elements/bigswitch-vns/test/com/cloud/network/bigswitch/BigSwitchApiTest.java
>  cab06ba 
>   
> plugins/network-elements/bigswitch-vns/test/com/cloud/network/resource/BigSwitchVnsResourceTest.java
>  514385f 
>   ui/dictionary.jsp 3aecaaa 
>   ui/scripts/system.js 4d529ae 
> 
> Diff: https://reviews.apache.org/r/9789/diff/
> 
> 
> Testing
> ---
> 
> Test to add a BigSwitch controller as a network service provider and view.
> Test to implementation of guest network on the controller
> Test to associate VM to its guest network
> 
> Test procedure:
> 1. Create an advanced zone with isolation = VNS
> 2. Add BigSwitch controller as the network service provider for the physical 
> network
> 3. Configure OVS on the host to point to the controller
> 4. Create two guest networks
> 5. Create two VM instances and make sure each VM belongs to the right network.
> 6. Confirm VMs in the same network can ping each other and the virtual router.
> 
> 
> Thanks,
> 
> Kanzhe Jiang
> 
>

Re: [PROPOSAL] EIP across zones

[Murali Reddy]

On 01/04/13 1:47 AM, "David Nalley"  wrote:

>On Fri, Mar 29, 2013 at 2:04 AM, Murali Reddy 
>wrote:
>> On 26/03/13 8:10 PM, "Adam Grochowski" 
>>wrote:
>>
>>>Hi,
>>>So I'm curious - what is the proposed method to move a single IP
>>>across zones (presuming these zones span regions).  As Chiradeep
>>>mentioned earlier, /24 is the largest block that will be advertised,
>>>so it would necessitate moving (or advertising in two locations, and
>>>back hauling back to one)  an entire class C to accomplish this (or
>>>some black magic like LISP).
>>
>> Adam, there is no proposed method to move IP across the zones. Having a
>> native capability in CloudStack to move IP across the zones does not
>>make
>> sense. We will be just assuming CloudStack will have control to many
>> infrastructure components (orchestrate route advertisements etc).
>>Instead
>> what is being proposed is, let the CloudStack raise an event when user
>> moves IP across the zones, then let admin act up on the event and
>>initiate
>> the IP availability from new zone. There is no assumption or proposed
>> method when and how admin to achieve this. Operator can opt for any
>> solution that works in distributed data centre setup.
>
>
>You don't have a proposed method for moving IPs between zones?
>Is this all a theoretical solution?

No, its not theoretical solution. Point I am trying to make is, CloudStack
need not have a native capability to move IP across zone. From the
CloudStack core perspective, all we need is abstraction of moving IP
(presented as NAT) across the zones. Then we can have specific
intelligence in the plug-ins which are providing EIP service. For
e.g.'Route Health Injection' is commonly used solution in distributed data
centres for disaster recovery supported by multiple vendors [1][2][3][4].
My initial plan was to enhance NetScaler plug-in to integrate with
NetScaler's RHI capability. But even to have such capability in plug-in
means CloudStack will have to make several assumptions on operational
aspects. So its better to off-load responsibility of IP advertisement to
the operators. Let me know if you still have any confusion. May be I will
add a reference deployment model/s once I progress with feature and test
it.

[1] 
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/dcstslt.ht
ml#wp53152
[2] http://www.nanog.org/meetings/nanog38/presentations/naseh.pdf
[3] 
http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-ip-
routing-administration-11-2-0/4.html
[4] 
http://support.citrix.com/servlet/KbServlet/download/30572-102-692240/NS-Ne
tworking-Guide.pdf  

>
>--David
>

[IP clearance] merge IP cleared features into master

[Murali Reddy]

I revoked the code for the features 'optional public IP assignment for EIP' [1] 
and 'network services in shared network' [2] features from master due to IP 
clearance issues. Both the features have passed IP clearance window [3][4]. Due 
to multiple refactors that happened at 4.1 code freeze time, patches are 
invalid now. I did not get time to work on new patch and test them out. I would 
like work (its almost rework now) on these features now and merge them back 
into master.

Let me know if there are any concerns.

[1] https://issues.apache.org/jira/browse/CLOUDSTACK-265
[2] https://issues.apache.org/jira/browse/CLOUDSTACK-312
[3] 
http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201301.mbox/%3ccakprhvzyidegdeu3ptb_dctzjc5xyutsof_p+gexkzhnt_+...@mail.gmail.com%3E
[4] 
http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201301.mbox/%3ccakprhvyp0xozlwuj7yomboi12a02c+woe0f9omke0k2uuxs...@mail.gmail.com%3E

Thanks,
Murali

Re: Review Request: Mulitiple ip address per nic support for advacned shared networks

[Murali Reddy]

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

Ship it!


submitted with 8dd0b7747b2da1aa71110e871b0bd4ffdbcdfcb4

- Murali Reddy


On April 1, 2013, 8:32 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10040/
> ---
> 
> (Updated April 1, 2013, 8:32 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Murali Reddy, and anthony 
> xu.
> 
> 
> Description
> ---
> 
> Changes added for supporting multiple ip address per nic for shared networks
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkServiceImpl.java d503459 
> 
> Diff: https://reviews.apache.org/r/10040/diff/
> 
> 
> Testing
> ---
> 
> 1. Tested adding and removing the ip for nic using the APIs
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: [DISCUSS] Palo Alto Integration

[Murali Reddy]

The 'Network' has a life cycle associated with it. Network goes from 
'allocated' state (after the design phase) to 'implemented' (after implement 
phase). Unless a network is implemented it is not ready for use in 'isolated 
network' case. Only after network is implemented, it gets full identity. Can 
you please deploy a Vm into the network and confirm you see that 
non-overlapping CIDR's is allocated? 10.1.1.0/24 you see is the default CIDR 
network gets after design phase which will be replaced once network is 
implemented.

From: Will Stevens mailto:wstev...@cloudops.com>>
Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, 2 April 2013 12:33 AM
To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Palo Alto Integration

So I have been stepping through the code and I can confirm that the 'design' 
method of ExternalGuestNetworkGuru is being hit, but it doesn't do anything, so 
it passes off work of creating the network to the 'design' method of 
GuestNetworkGuru which assigns 10.1.1.0/24<http://10.1.1.0/24> to the network 
every time I create a network.

Something I am finding strange is that 'config.getId()' gives -1, so the new 
network that is being created while in the 'design' method of 
ExternalGuestNetworkGuru does not hit the only logic in the function:

NetworkVO config = (NetworkVO) super.design(offering, plan, userSpecified, 
owner);
if (config == null) {
return null;
} else if 
(_networkModel.networkIsConfiguredForExternalNetworking(plan.getDataCenterId(), 
config.getId())) {
/* In order to revert userSpecified network setup */
config.setState(State.Allocated);
}

So the config.setState(State.Allocated) is not getting hit.

There does seem to be some logic for updating the cidr in the 'implement' 
function of ExternalGuestNetworkGuru, but that is not run until a VM is added 
to the network (from what I understand), so that is a bit strange to me.

Are the non-overlapping cidrs implemented only when a VM is added to the 
network and the same placeholder cidr is used until then?

Thanks,

Will


On Mon, Apr 1, 2013 at 11:22 AM, Will Stevens 
mailto:wstev...@cloudops.com>> wrote:
Thank you for all your help Murali...

So my Provider has been setup with isExternal = true this whole time.
public static final Provider PaloAlto = new Provider("PaloAlto", true);

If I run a debugger and then create a guest network, I see it enter the 
'design' function of the ExternalGuestNetworkGuru, but it does not do anything 
in there because the config is not null, but the config.getId() = -1, so it 
just returns the config (Network object) and doesn't really do anything.

Apparently the 'implement' method doesn't get called until a VM is attempted to 
be launched on the network.

I must be missing something because, every Isolated guest network I create on 
my provider is defaulting to the cidr of 10.1.1.0/24<http://10.1.1.0/24>.  Even 
if I have multiple Isolated networks associated with the same account, they all 
by default have that cidr.

If the default behaviour of the ExternalGuestNetworkGuru is to create 
non-overlapping guest cidrs, why does it always default to the 
10.1.1.0/24<http://10.1.1.0/24> cidr when I create a new network?  I can not 
specify a gateway or netmask because it is an external network (as you can see 
from the included screenshot).
[Inline image 1]

What am I missing here?  Why am I unable to create non-overlapping cidrs with 
the ExternalGuestNetworkGuru?

Thanks,

Will


On Fri, Mar 29, 2013 at 1:23 AM, Murali Reddy 
mailto:murali.re...@citrix.com>> wrote:
On 28/03/13 10:59 PM, "Will Stevens" 
mailto:wstev...@cloudops.com>> wrote:

>I am trying to implement the non-overlapping cidrs right now and I have
>some questions.  Does the ExternalGuestNetworkGuru create networks with
>non-overlapping cidrs by default?  Or do I need to override it's 'design'
>and 'implement' methods to implement non overlapping cidrs?

Will, yes, it does by default. You can just use
'ExternalGuestNetworkGuru'. Just so that you know, there is check
'networkIsConfiguredForExternalNetworking' in ExternalGuestNetworkGuru.
Which basically checks if provider is configured as service provider using
external physical appliances. So when you declare provider, mark
'isExternal' as true in the provider constructor.

>
>If I have to write my own methods, I think I understand how to
>override ExternalGuestNetworkGuru and then get it to run by adding it to
>the components.xml (or nonoss-components.xml) as well as the
>componentContext.xml.in<http://

Re: [IP clearance] merge IP cleared features into master

[Murali Reddy]

On 01/04/13 7:03 PM, "Chip Childers"  wrote:

>On Mon, Apr 01, 2013 at 07:00:07AM +, Murali Reddy wrote:
>> I revoked the code for the features 'optional public IP assignment for
>>EIP' [1] and 'network services in shared network' [2] features from
>>master due to IP clearance issues. Both the features have passed IP
>>clearance window [3][4]. Due to multiple refactors that happened at 4.1
>>code freeze time, patches are invalid now. I did not get time to work on
>>new patch and test them out. I would like work (its almost rework now)
>>on these features now and merge them back into master.
>> 
>> Let me know if there are any concerns.
>
>+1
>
>I'd suggest creating a feature branch, and then requesting a merge once
>you have things sorted out (WRT the refactoring that forces changes to
>the previously approved patches).

Ok, will go through the regular process.

>
>> 
>> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-265
>> [2] https://issues.apache.org/jira/browse/CLOUDSTACK-312
>> [3] 
>>http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201301.
>>mbox/%3ccakprhvzyidegdeu3ptb_dctzjc5xyutsof_p+gexkzhnt_+...@mail.gmail.co
>>m%3E
>> [4] 
>>http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201301.
>>mbox/%3ccakprhvyp0xozlwuj7yomboi12a02c+woe0f9omke0k2uuxs...@mail.gmail.co
>>m%3E
>> 
>> Thanks,
>> Murali
>

[ACS41][Patch Request] CLOUDSTACK-1834: Events are not generated for registerUserKeys()

[Murali Reddy]

CLOUDSTACK-1834: Events are not generated for registerUserKeys()

Branch: refs/heads/master
Commit: 9180bd599015ce248e894a0ef476a4604b1533e4
Parents: 47dc989
Author: Murali Reddy mailto:murali.re...@citrix.com>>
Authored: Tue Apr 9 17:45:19 2013 +0530
Committer: Murali Reddy 
mailto:murali.re...@citrix.com>>
Committed: Tue Apr 9 17:45:57 2013 +0530

Re: [ACS41] Outstanding work for the release

[Murali Reddy]

On 08/04/13 7:51 PM, "Chip Childers"  wrote:
>
>CLOUDSTACK-1834 Events are not generated for registerUserKeys(), Enabling
>account and Editing account.  Murali Reddy
>Murali - In your opinion, is this blocking the release?  If not, let's
>change the priority to major.  If so, any ETA on a fix?


Submitted a patch request for 4.1

Re: Network architecture question

[Murali Reddy]

Justin,

As Chiradeep mentioned, 'basic zone' is solution you should be trying out.
With basic zone, you could associate guest subnet per pod, there is no
VLAN's required in the zone. Your L2 broadcast domain is restricted to
POD. POD becomes unit of scale in basic zone, so east-west traffic across
the rack/POD's is through the router that connects TOR switches of POD.
Please try basic zone deployment and let us know if you still see
limitations.

-Murali

On 10/04/13 7:13 PM, "Justin Grudzien"  wrote:

>I looked at Security groups and I am not sure how this solves my
>problems. Sure it provides guest isolation but that is through the
>virtual router correct? The underlying physical network --outside of
>cloudstack-- is still layer 2? That is what I am concerned with. When
>defining what IPs my guests sit on CloudStack assumes that those are
>available, or tagged, on every host in my zone. If I have every host
>tagged with the guest network then broadcast packets, like ARP, will hit
>every box, regardless of whether a VM runs on it at all. My network
>engineers are worried that any kind of broadcast storm, or spanning tree
>loop, could take the whole cloud down. Does this make sense or am I still
>missing something?
>
>What we are looking at is creating a zone per physical rack of servers
>implementing the shared network offering. This allows my underlying
>network to be layer 3 between cabinets and limits my layer 2 guest
>traffic to far less servers. Between cabinets I will use routing for VMs
>to talk to each other. The problems this introduces is that CloudStack
>doesn't let me mount the same secondary storage for images so I have to
>replicate that data. It would be nice to be able to mount the images
>across all zones but leave the snapshots local to the zone.
>
>We have been intensively building and rebuilding CloudStack for the last
>three weeks and nowhere have I seen the ability to pin a guest subnet to
>a rack (pod) of servers. This is what suggests that the guest networks
>must be tagged on all physical host ports and why I am concerned about
>the large layer 2 domain.
>
>Sorry this was long winded some of these concepts are difficult I convey
>over email.
>
>Justin 
>
>Sent from my iPhone
>
>On Apr 9, 2013, at 12:26 PM, Chiradeep Vittal
> wrote:
>
>> You can do bonded nics in basic zone. The limitation with basic zone is
>> that the Vms cannot have multiple nics. Did you need multiple nics for
>> your vms?
>> If you need advanced network services such as static NAT and load
>> balancing, advanced networking is probably your best bet (currently,
>> unless you want to invest in a Netscaler for these services).
>> 
>> Not sure that VXLAN will solve your problems since that has scaling
>> problems as well. On vSphere an NX1000v DVS can only handle about 64
>> hypervisors IIRC.
>> 
>> 
>> 
>> On 4/9/13 5:39 AM, "Justin Grudzien"  wrote:
>> 
>>> We have 2 pairs of bonded 10g nics on each box. Wouldn't that require
>>>an
>>> advanced network? Is it possible to do the security groups with small
>>>L2
>>> networks in advanced networking?
>>> 
>>> Justin 
>>> 
>>> Sent from my iPhone
>>> 
>>> On Apr 9, 2013, at 12:38 AM, Chiradeep Vittal
>>>  wrote:
>>> 
 Have you considered using a basic zone?
 With security groups you can have *lots* (thousands of) with very
small
 L2
 networks.
 
 On 4/8/13 10:28 PM, "Justin Grudzien"  wrote:
 
> My team has been working for three weeks with CloudStack architecture
> design and we are struggling to put together a network architecture
> that
> we feel will scale. From everything I can tell, CloudStack requires
>a a
> very large layer 2 network when using shared guest networks. We are
> looking to deploy almost a thousand physical hosts across 25 cabinets
> with over 4000 VMs in the next 18 months and having a broadcast
>domain
> this large feels problematic.
> 
> How have others solved this problem? I don't have a need or a desire
> for
> isolation and even if I had 100 guest networks I would still have to
> tag
> their VLANs into every host port. There doesn't seem to be a way to
> tie a
> network to anything smaller than a zone.
> 
> One solution we are looking into is Cisco's 1000v and utilizing
>VXLANs.
> This will allow us scale down the broadcast domains. I don't think
> CloudStack has support in configuring their VXLAN settings? Any
> comments
> or suggestions would be appreciated.
> 
> Justin
>> 
>

[MERGE] shared network services branch to master

[Murali Reddy]

I would like merge back the IP cleared [1] 'network services in shared 
networks' [2] feature back to master. I worked out 'sharednetworkservices' 
branch and kept up to date with master.

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-cloudstackdev/201301.mbox/%3ccakprhvyp0xozlwuj7yomboi12a02c+woe0f9omke0k2uuxs...@mail.gmail.com%3E
[2] https://issues.apache.org/jira/browse/CLOUDSTACK-312
[3] 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/sharednetworkservices

[ACS41][Patch Request] CLOUDSTACK-1934: NPE with listSupportedNetworkServices

[Murali Reddy]

Please cherry-pick to 4.1

CLOUDSTACK-1934: NPE with listSupportedNetworkServices

For 'connectivity' network service current set of providers (MidoNet,
NiciraNcp) not necessarily part of OSS builds. So handle the case where
there are no providers for a service

Branch: refs/heads/master
Commit: c0419791ede331fff7151a5cee9a358c0400c272
Parents: 4ae3e5d
Author: Murali Reddy mailto:murali.re...@citrix.com>>
Authored: Fri Apr 12 16:44:03 2013 +0530
Committer: Murali Reddy 
mailto:murali.re...@citrix.com>>
Committed: Fri Apr 12 16:47:50 2013 +0530

Re: [ACS41] Help needed clearing bugs!

[Murali Reddy]

On 12/04/13 2:41 AM, "Chip Childers"  wrote:
>
>CLOUDSTACK-1934 NPE with listSupportedNetworkServices after upgrade from
>4.0 to 4.1 (Ubuntu MS)
>Unassigned

Submitted patch for 1934.

Re: [QA][PROPOSAL][ACS4.2] Test plan review: GSLB (Global Server Load Balancing)

[Murali Reddy]

Thanks for test plan. Test plan looks good to me.For the below questions
you raised in the test plan please open a bug.

1. Provide a mechanism for updating information about existing Netscaler
device that is enabled for GSLB (like change isGslbProvider from True to
False and vice versa etc..,)
2. Prvide a mechanism for reprogramming GSLB info on the network devices
in case of any changes or configuration lost /messed up situations.



On 12/04/13 8:51 AM, "Venkata SwamyBabu Budumuru"
 wrote:

>
>Hi Murali,
>
>Please review the test plan [1] for feature " GSLB (Global Server Load
>Balancing)" and let me know the review comments. The test cases are
>mentioned in an excel sheet attached to the page.
>
>[1] Test Plan  :
>https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=31817730
>[2] Functional Spec:
>https://cwiki.apache.org/CLOUDSTACK/gslb-global-server-load-balancing-func
>tional-specification-and-design-document.html
>[3] Bug Id   :
>https://issues.apache.org/jira/browse/CLOUDSTACK-894
>
>
>Thanks,
>SWAMY
>
>

Re: [RFC][FS]PVLAN for isolation within a VLAN

[Murali Reddy]

Sheng,

Thanks for the FS. Couple of points in FS that made me curious of the
rational behind it.

Why do you want to all the end user VM's (except for DHCP server VM) in
shared network to be connected only to I-port's. This means that even VM's
of same user can not talk to each other, right? Is'nt it too restrictive?
How about having community secondary VLAN per user with which they gets
the isolation and their VM's can talk to each other? Only down side is
there is additional effort of managing pool of secondary community VLAN's
or there are other challenges?

Approach proposed for Xen and KVM which does not support PVLAN is
interesting. So do you expect the admin to setup these flows on each
KVM/Xen hypervisor? Or CloudStack will be responsible for set-up of flow
tables as well?

Thanks.


On 17/04/13 5:01 AM, "Sheng Yang"  wrote:

>Hi all,
>
>I am current working on a new mechanism to archive isolation for advance
>shared network. It took advantage of PVLAN feature of Cisco switch, to
>achieve isolation using a simpler way.
>
>Here is the FS. You probably need to read references(in the link) to get
>an
>idea of PVLAN first.
>
>https://cwiki.apache.org/CLOUDSTACK/pvlan-for-isolation-within-a-vlan.html
>
>Thanks!
>
>--Sheng
>

Re: [RFC][FS]PVLAN for isolation within a VLAN

[Murali Reddy]

On 18/04/13 6:29 AM, "Chip Childers"  wrote:

>On Wed, Apr 17, 2013 at 05:49:23PM -0700, Sheng Yang wrote:
>> In fact that's the requirement for this design. We need this very strict
>> restriction to implement isolation for the VMs. PVLAN is the way we
>>used to
>> approach this requirement.
>
>As a user, the whole point of this type of network is to support a
>"backend"
>management / monitoring network that can be connected to VMs regardless
>of the user of the VM.

I see. I get the use-case of using 'secondary isolated VLAN' for
backup/management this proposal is targetting.
 

> Using a VLAN per tenant isn't actually enough
>even, when you consider the N-Tier apps feature.  If a user has 3
>"tiers" using traditional VLAN isolation, you are basically tied to a
>model of 2 VLANs per tier, burning through VLANs much faster than
>necessary.  PVLANs (and the equiv via OVS flows) are the normal way to
>accomplish this in a traditional hosting environment.

Not sure I understand your point here. My question was about use-case of
'secondary community VLAN' as VLAN alternative for tenant isolation, if
that can solve 4096 limitation. May be PVLAN is not adopted/considered as
isolation solution, compared to say VXLAN/NVGRE/STT. So use-case itself
may not be that value.

Nevertheless, good add to CloudStack networking, +1 for the proposal. 

Re: DnsNotifier Example

[Murali Reddy]

Since its a example class, its not added in the client war file that jetty
runs. Please add a dependency in client/pom.xml as below

 
   org.apache.cloudstack
   cloud-plugin-example-dns-notifier
   ${project.version}
 



On 19/04/13 5:58 AM, "Soheil Eizadi"  wrote:

>I am trying to run the DnsNotifier example in my CloudStack Environment,
>I am having trouble with the Spring wiring. I modified the
>DnsNotifier.java file to add @Component annotation and modified the two
>files componentContext.xml.in and nonossComponentContext.xml.in to add
>reference to the DnsNotifier. I get everything to build but the Spring
>Class Loader can not find DnsNotifier Class to load, what more needs to
>be done to get this to run?
>-Soheil
>
>ovider,databaseUpgradeChecker,configurationDaoImpl,GlobalLoadBalancingRule
>sServiceImpl,DnsNotifier,niciraNvpDaoImpl,niciraNvpNicMappingDaoImpl,nicir
>aNvpRouterMappingDaoImpl,NiciraNvpGuestNetworkGuru,NiciraNvp,MidoNetGuestN
>etworkGuru,MidoNetElement,userAuthenticators,userPasswordEncoders,security
>Checkers,resourceDiscoverers,haInvestigators,haFenceBuilders,deploymentPla
>nners,podAllocators,hostAllocators,storagePoolAllocators,ipDeployers,dhcpP
>roviders,networkGurus,networkElements,org.springframework.context.annotati
>on.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor#0]; root
>of factory hierarchy
>ERROR [web.context.ContextLoader] (main:) Context initialization failed
>org.springframework.beans.factory.BeanCreationException: Error creating
>bean with name 'actionEventUtils': Injection of autowired dependencies
>failed; nested exception is
>org.springframework.beans.factory.BeanCreationException: Could not
>autowire field: com.cloud.event.dao.EventDao
>com.cloud.event.ActionEventUtils.eventDao; nested exception is
>org.springframework.beans.factory.CannotLoadBeanClassException: Cannot
>find class [org.apache.cloudstack.network.element.DnsNotifier] for bean
>with name 'DnsNotifier' defined in class path resource
>[componentContext.xml]; nested exception is
>java.lang.ClassNotFoundException:
>org.apache.cloudstack.network.element.DnsNotifier
>
>Administrators-MacBook-Pro-7:cloudstack seizadi$ find . -name
>DnsNotifier.class
>./plugins/network-elements/dns-notifier/target/classes/org/apache/cloudsta
>ck/network/element/DnsNotifier.class
>
>diff --git 
>a/plugins/network-elements/dns-notifier/src/org/apache/cloudstack/network/
>element/DnsNotifier.java
>b/plugins/network-elements/dns-notifier/src/org/apache/cloudstack/network/
>element/DnsNotifier.java
>index c421344..8f8986d 100644
>--- 
>a/plugins/network-elements/dns-notifier/src/org/apache/cloudstack/network/
>element/DnsNotifier.java
>+++ 
>b/plugins/network-elements/dns-notifier/src/org/apache/cloudstack/network/
>element/DnsNotifier.java
>@@ -22,7 +22,9 @@ import java.util.Map;
> import java.util.Set;
>
> import javax.ejb.Local;
>-import javax.naming.ConfigurationException;
>+
>+import org.apache.log4j.Logger;
>+import org.springframework.stereotype.Component;
>
> import com.cloud.deploy.DeployDestination;
> import com.cloud.exception.ConcurrentOperationException;
>@@ -45,13 +47,17 @@ import com.cloud.vm.VirtualMachineProfile;
>  * @author ahuang
>  *
>  */
>+
>+@Component
> @Local(NetworkElement.class)
> public class DnsNotifier extends AdapterBase implements NetworkElement {
>
>
>diff --git a/client/tomcatconf/componentContext.xml.in
>b/client/tomcatconf/componentContext.xml.in
>index bea2f78..202a998 100644
>--- a/client/tomcatconf/componentContext.xml.in
>+++ b/client/tomcatconf/componentContext.xml.in
>@@ -46,6 +46,14 @@
>   class="com.cloud.configuration.dao.ConfigurationDaoImpl" />
>
>   ="org.apache.cloudstack.region.gslb.GlobalLoadBalancingRulesServiceImpl"
>/>
>+
>+  class="org.apache.cloudstack.network.element.DnsNotifier">
>+
>+  
>+
>
>  
>   
>
>diff --git a/client/tomcatconf/nonossComponentContext.xml.in
>b/client/tomcatconf/nonossComponentContext.xml.in
>index fc8a9cd..9da3d06 100644
>--- a/client/tomcatconf/nonossComponentContext.xml.in
>+++ b/client/tomcatconf/nonossComponentContext.xml.in
>@@ -79,6 +79,13 @@
>   class="com.cloud.hypervisor.vmware.resource.VmwareContextFactory" />
>
>+  class="org.apache.cloudstack.network.element.DnsNotifier">
>+
>+  
>+
>+  
>   class="com.cloud.network.dao.NiciraNvpDaoImpl" />
>@@ -331,6 +338,8 @@
>   
>   
>   
>+  
> 

Re: [ASFCS42] Proposed schedule for our next release

[Murali Reddy]

Pardon my ignorance of project management, but it appears to me we are
talking of managing a release after half way through the cycle. May be
this is orthogonal discussion, but how about taking approach of planning a
release early in the cycle (at least for future releases)? Having a time
window between each release where we actually plan for the next release.
Discussions include - direction of the project, what big features are to
be included, rough estimate of the effort, risks and timelines would help
in planning releases better? Perhaps we should use Collab conferences for
this purpose, where we can plan for the next release (apart from show
casing the features of previous release). Since Collab is also scheduled
to happen on a half-yearly timeline it makes this easier to execute
release management starting from there.


On 19/04/13 8:21 AM, "Chip Childers"  wrote:

>On Apr 18, 2013, at 10:29 PM, David Nalley  wrote:
>
>> On Thu, Apr 18, 2013 at 10:26 PM, Chiradeep Vittal
>>  wrote:
>>>
>>>
>>> On 4/18/13 6:41 PM, "David Nalley"  wrote:
>>>
 On Thu, Apr 18, 2013 at 6:26 PM, Will Chan 
wrote:
>
>> -Original Message-
>> From: Chip Childers [mailto:chip.child...@sungard.com]
>> Sent: Monday, April 15, 2013 7:22 AM
>> To: dev@cloudstack.apache.org
>> Cc: cloudstack-...@incubator.apache.org
>> Subject: Re: [ASFCS42] Proposed schedule for our next release
>>
>> On Thu, Apr 11, 2013 at 02:50:02PM -0700, Animesh Chaturvedi wrote:
>>>
>>> I want to call out my concern on technical debt we have accumulated
> so
>> far.
>>>
>>> I did an analysis on JIRA bugs yesterday night PST on "Affects
>>> Version = 4.1" and created since Dec 2012
>>>
>>> Total records : 429
>>> Resolution Type (Invalid, Duplicate, Cannot reproduce etc.) : 87
>>>(30
>>> Blockers, 27 Critical, 27 Major, 4 Minor) Valid Defects  : 429-87=
> 342
>>> Fixed : 246 (60 Blockers, 70 Critical, 99 Majors) out of which 217
>>> were fixed since Feb Unresolved : 96 (1 Blocker, 8 Critical, 64
> Major)
>>>
>>> With this data it looks like we have fixed 2/3 of valid defects in
> little over
>> 2 months and pretty much deferring around 1/3 rd of issues for
>>future
>> release.
>>>
>>> I also looked at overall backlog of bugs (Critical, Major and
> Blockers only)
>> as of 4/10/2013 - 10:0PM PST.
>>>
>>> 284 open (18 Blocker, 38 Critical, 228 Major) ; By Fix version
>>>-  Release 4.0.x and prior: 13
>>>-  4.1: 70
>>>-  4.2 : 97
>>>-  Future: 8
>>>-  No version: 107
>>>
>>> Looking at that we fixed 217 bugs in roughly 2 months during 4.1
> cycle,
>> fixing the backlog of bug  will probably take us 2 months.  Should
>>we
> extend
>> the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22,
> Extended
>> Schedule: 6/1-9/22] to reduce the technical debt significantly? I
> would like
>> to hear how community wants to address technical debt. Based on the
>> input and consensus I will publish the agreed schedule next week.
>>
>> I don't think that an extension of time changes bug counts really.
> IMO, we
>> need to pull together to have some bug-fix focused effort applied to
> the
>> code-base.  It's also another reason that I'm so big on making sure
> that
>> automated tests come in with the new features.  That doesn't address
> test
>> scenarios that human testers can come up with, but if a developer
> spends
>> the time to think about testing the basic feature and codifies that,
> we
>> should at least avoid the "this actually doesn't work at all" types
> of bugs.
>>
>> There's a school of thought that says, don't build another feature
> until you
>> have sorted out the known bugs in the current features.  I don't
> think we
>> could really pull that off, but perhaps a different thread to rally
> people
>> around the bug backlog is in order?
>>
>> -chip
>
> Sorry to chime in so late to this thread as I've been offsite for the
> better part of this week.  I was one of the original 4 month release
> crowd but after the recent two releases of ACS, I'm starting to
>wonder
> if we shouldn't start moving this to a 6 month cycle instead of two.
> Here are some high level observations based on the previous two
>releases:
>
> 1. It doesn't seem like we are on a true 4 month time based release
> schedule.  Both 4.0 and 4.1 were delayed more than several weeks
>past the
> original proposed GA date.  4.0 was released 11/6 and let's assume
>that
> 4.1 will ship within a week or two.  That's almost a 6 month release
> cycle.

 So both 4.0 and 4.1 strike me as extraordinary. 4.0 was our first
 release - and we had lots of issues to resolve. 4.1 introduced

Re: Review Request: Updated the user permission to acquire ip

[Murali Reddy]

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



server/src/com/cloud/network/NetworkServiceImpl.java
<https://reviews.apache.org/r/10727/#comment40527>

you need to check for both 'isolated' & 'shared' networks of advanced zone.



server/src/com/cloud/network/NetworkServiceImpl.java
<https://reviews.apache.org/r/10727/#comment40526>

You need to check for only basic zone here. 'shared' network of advanced 
zone is different from 'shared' network of basic zone w.r.t to guest IP 
allocation.



server/src/com/cloud/network/NetworkServiceImpl.java
<https://reviews.apache.org/r/10727/#comment40525>

this check is required, dont remove it.



server/src/com/cloud/network/NetworkServiceImpl.java
<https://reviews.apache.org/r/10727/#comment40524>

This check needs to be done for both advanced/basic zones and 
isolate/shared networks.

also you need to check if NIC is owned/usable by caller. No need for check 
access on VM


- Murali Reddy


On April 23, 2013, 10:55 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10727/
> ---
> 
> (Updated April 23, 2013, 10:55 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Description
> ---
> 
> Updated the user permissions check
> 
> 
> This addresses bug CLOUDSTACK-2134.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkServiceImpl.java ac2ac45 
> 
> Diff: https://reviews.apache.org/r/10727/diff/
> 
> 
> Testing
> ---
> 
> Unit tested on basic and advanced zone
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request: updated the listnics response for non-root user

[Murali Reddy]

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



server/src/com/cloud/api/ApiResponseHelper.java
<https://reviews.apache.org/r/10703/#comment40528>

I don't think we should be passing VLAN information in NicResponse. 


Its important that we pass network ID to which this NIC belong. I dont see 
network id being set in the nic response. 


- Murali Reddy


On April 22, 2013, 11:10 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10703/
> ---
> 
> (Updated April 22, 2013, 11:10 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Description
> ---
> 
> Updated listnics response for normal user
> 
> 
> This addresses bug CLOUDSTACK-1573.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/ApiResponseHelper.java a7d6165 
> 
> Diff: https://reviews.apache.org/r/10703/diff/
> 
> 
> Testing
> ---
> 
> Tested with admin and normal user
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request: updated the listnics response for non-root user

[Murali Reddy]

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



server/src/com/cloud/api/ApiResponseHelper.java
<https://reviews.apache.org/r/10703/#comment40643>

if IPv6 address is present then setIpv6 address in the nic response.


- Murali Reddy


On April 25, 2013, 5:03 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10703/
> ---
> 
> (Updated April 25, 2013, 5:03 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Description
> ---
> 
> Updated listnics response for normal user
> 
> 
> This addresses bug CLOUDSTACK-1573.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/ApiResponseHelper.java cd0158d 
> 
> Diff: https://reviews.apache.org/r/10703/diff/
> 
> 
> Testing
> ---
> 
> Tested with admin and normal user
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request: updated the listnics response for non-root user

[Murali Reddy]

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

Ship it!


Ship It!

- Murali Reddy


On April 25, 2013, 7:06 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10703/
> ---
> 
> (Updated April 25, 2013, 7:06 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Description
> ---
> 
> Updated listnics response for normal user
> 
> 
> This addresses bug CLOUDSTACK-1573.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/ApiResponseHelper.java 894ec8d 
> 
> Diff: https://reviews.apache.org/r/10703/diff/
> 
> 
> Testing
> ---
> 
> Tested with admin and normal user
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request: Throwing error for while configuring egress rules for shared networks

[Murali Reddy]

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

Ship it!


submitted with 318c7f2af0a664c057ec1ed057ccaad608339f62

Please open a different bug, for supporting 'egress firewalls' when firewall 
service is enabled in shared networks.

- Murali Reddy


On April 26, 2013, 9:08 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10794/
> ---
> 
> (Updated April 26, 2013, 9:08 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Description
> ---
> 
> For shared networks the egress rules are not supported so throwing error when 
> configuring egress rules for shared networks.
> 
> 
> This addresses bug CLOUDSTACK-1794.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/firewall/FirewallManagerImpl.java 080f7b0 
> 
> Diff: https://reviews.apache.org/r/10794/diff/
> 
> 
> Testing
> ---
> 
> 1. Added egress rules for shared network.
> 2. Got error 'Egress firewall rules are not supported for shared networks"
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request: CLOUDSTACK-1851 [AWS Style Health Checks] Health Check monitor not getting created on Netscaler device in Basic zone setup.

[Murali Reddy]

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

Ship it!


commit 16865014a05ab04bb608a8122a7229b2b0ae3421
Author: Rajesh Battala 
Date:   Wed Apr 17 18:22:30 2013 +0530

- Murali Reddy


On April 17, 2013, 1:20 p.m., Rajesh Battala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10572/
> ---
> 
> (Updated April 17, 2013, 1:20 p.m.)
> 
> 
> Review request for cloudstack, Murali Reddy, Vijay Venkatachalam, and Ram 
> Ganesh.
> 
> 
> Description
> ---
> 
> Fixed the issue
> 1.While creating the LB rule, healthcheck policies were not sent, so they are 
> not getting created. Fixed the issue by including them in TO constructor.
> 2. Fetching the status of healthchecks created in basic zone.
> 
> 
> This addresses bug CLOUDSTACK-1851.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/element/NetscalerElement.java
>  2bbdb04 
> 
> Diff: https://reviews.apache.org/r/10572/diff/
> 
> 
> Testing
> ---
> 
> Created basiczone setup with Netscaler.
> 
> 1. Verified creation/deletion of healthchecks on LB rules
> 2. Verified creation of healthchecks with different param values.
> 3. Verified the Healthcheck manager is updating the status of the services in 
> the lb vm map table.
> 4. Verified deletion of healthchecks, resetting the status of services to null
> 5. Deletion of healthcheck will do clean up of healthcheck entires in 
> cloudstack db and in Netscaler resource.
> 
> 
> Thanks,
> 
> Rajesh Battala
> 
>

Re: Review Request: Source NAT on private gateway feature

[Murali Reddy]

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


changes look good. But patch does not apply. Can you please re-submit patch 
that applies to master.

- Murali Reddy


On April 29, 2013, 6:57 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10833/
> ---
> 
> (Updated April 29, 2013, 6:57 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Murali Reddy, and 
> Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> Source NAT on private gateway feature
> 
> 
> This addresses bug CLOUDSTACK-1828.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkService.java 6c9bebc 
>   api/src/com/cloud/network/vpc/PrivateIp.java 857fc22 
>   api/src/com/cloud/network/vpc/VpcGateway.java 1756616 
>   api/src/com/cloud/network/vpc/VpcService.java 07ce89b 
>   
> api/src/org/apache/cloudstack/api/command/admin/vpc/CreatePrivateGatewayCmd.java
>  9fd736f 
>   api/src/org/apache/cloudstack/api/response/PrivateGatewayResponse.java 
> 4123477 
>   
> core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java 
> 7148e07 
>   patches/systemvm/debian/config/opt/cloud/bin/vpc_privateGateway.sh a09d8f7 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  0064edf 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  99ad1ca 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  46ae35a 
>   server/src/com/cloud/api/ApiResponseHelper.java 6090ff0 
>   server/src/com/cloud/network/NetworkServiceImpl.java 2dcb47d 
>   
> server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
>  bdfac06 
>   server/src/com/cloud/network/vpc/PrivateGatewayProfile.java 2595a6a 
>   server/src/com/cloud/network/vpc/PrivateIpAddress.java 826bea2 
>   server/src/com/cloud/network/vpc/PrivateIpVO.java e6616ae 
>   server/src/com/cloud/network/vpc/VpcGatewayVO.java 718e4df 
>   server/src/com/cloud/network/vpc/VpcManagerImpl.java 224a680 
>   server/test/com/cloud/network/MockNetworkManagerImpl.java e9987bd 
>   server/test/com/cloud/vpc/MockNetworkManagerImpl.java 9b18358 
>   server/test/com/cloud/vpc/MockVpcManagerImpl.java 0f26928 
>   setup/db/db/schema-410to420.sql 78444fd 
> 
> Diff: https://reviews.apache.org/r/10833/diff/
> 
> 
> Testing
> ---
> 
> 1. created the private gateway with source nat enable.
> 2. created private gateway with with source nat disable.
> 3. NAT rules for private gateway interface are configured correctly on VR.
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request: Source NAT on private gateway feature

[Murali Reddy]

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

Ship it!


commit 1f1467974f77901bcde0c1c52ac4286185dcc333
Author: Jayapal 
Date:   Thu May 2 15:24:21 2013 +0530

CLOUDSTACK-1828 Source Nat on private gateway feature

- Murali Reddy


On May 2, 2013, 10:02 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10833/
> ---
> 
> (Updated May 2, 2013, 10:02 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Murali Reddy, and 
> Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> Source NAT on private gateway feature
> 
> 
> This addresses bug CLOUDSTACK-1828.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkService.java 6c9bebc 
>   api/src/com/cloud/network/vpc/PrivateIp.java 857fc22 
>   api/src/com/cloud/network/vpc/VpcGateway.java 1756616 
>   api/src/com/cloud/network/vpc/VpcService.java 07ce89b 
>   
> api/src/org/apache/cloudstack/api/command/admin/vpc/CreatePrivateGatewayCmd.java
>  9fd736f 
>   api/src/org/apache/cloudstack/api/response/PrivateGatewayResponse.java 
> 4123477 
>   
> core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java 
> 7148e07 
>   patches/systemvm/debian/config/opt/cloud/bin/vpc_privateGateway.sh a09d8f7 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  0064edf 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  38c9f86 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  46ae35a 
>   server/src/com/cloud/api/ApiResponseHelper.java 6090ff0 
>   server/src/com/cloud/network/NetworkServiceImpl.java ae0e421 
>   
> server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
>  bdfac06 
>   server/src/com/cloud/network/vpc/PrivateGatewayProfile.java 2595a6a 
>   server/src/com/cloud/network/vpc/PrivateIpAddress.java 826bea2 
>   server/src/com/cloud/network/vpc/PrivateIpVO.java e6616ae 
>   server/src/com/cloud/network/vpc/VpcGatewayVO.java 718e4df 
>   server/src/com/cloud/network/vpc/VpcManagerImpl.java bc7bb0c 
>   server/test/com/cloud/network/MockNetworkManagerImpl.java e9987bd 
>   server/test/com/cloud/vpc/MockNetworkManagerImpl.java 9b18358 
>   server/test/com/cloud/vpc/MockVpcManagerImpl.java 0f26928 
>   setup/db/db/schema-410to420.sql 69bf886 
> 
> Diff: https://reviews.apache.org/r/10833/diff/
> 
> 
> Testing
> ---
> 
> 1. created the private gateway with source nat enable.
> 2. created private gateway with with source nat disable.
> 3. NAT rules for private gateway interface are configured correctly on VR.
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>