Re: cloudmonkey printing enhancements proposal
Hey Justin, thanks for posting this on community ML.
On Sat, Mar 30, 2013 at 9:20 AM, Justin Grudzien wrote:
> My company is building a private cloud and we are moving to cloudstack. As
> we begun investigating the cloudmonkey CLI we found that the output was
> slightly hard to read. I have begun working on some optimizations that I
> think will benefit the community and I reached out to Rohit, who
> recommended that I join this list and present my ideas. Here is what I am
> proposing:
>
> 1. Add json output to cloudmonkey
> I have accomplished this by adding a config parameter called display, which
> can be set to json, tabularize, or default. I have removed the tabularize
> parameter.
>
+1
>
> Justins-MacBook-Pro:cloudmonkey grudzien$ cloudmonkey list users
> account=grudzien
> {
> "count": 1,
> "user": [
> {
> "account": "grudzien",
> "accountid": "b799783d-e5bb-460a-be0e-3966bd69edda",
> "accounttype": 1,
> "apikey": "*nokey*",
> "created": "2013-03-27T16:09:17-0500",
> "domain": "ROOT",
> "domainid": "7e61c32f-9873-4944-947a-dcc00d3bebdc",
> "email": "grudz...@gmail.com",
> "firstname": "Justin",
> "id": "265930bc-62ef-41f8-849c-e58593ca4b1f",
> "lastname": "Grudzien",
> "secretkey": "*nokey*",
> "state": "enabled",
> "username": "grudzien"
> }
> ]
> }
>
> 2. Add filtering as a standard parameter for all output types.
> The only thing that has filtering now is the tabular output and grep breaks
> the json.
>
> Justins-MacBook-Pro:cloudmonkey grudzien$ cloudmonkey list users
> account=grudzien filter=account,email,username,state
> {
> "count": 1,
> "user": [
> {
> "account": "grudzien",
> "email": "grudz...@gmail.com",
> "state": "enabled",
> "username": "grudzien"
> }
> ]
> }
>
Awesome.
>
> 3. Add color to the json output
> I was thinking of colorizing the keys in the key/value pairs to increase
> readability.
>
This is easily doable, all we have to do is define a regex rule in
printer.py for the regex type "txt": as key and ": xxx, as value.
> 4. Move the color option from the config file to the command line.
> There are two reasons for this. First, I want to be able to wrap a script
> around cloudmonkey and not have to worry about colorization that will
> impede me processing the output and second I think it would be more useful
> to use the highlighting on demand rather than having to back out of the
> shell to edit a config file.
>
I did not understand this one. What exactly are you proposing? You can
always set color to false or true. Are you talking about color themes?
> 5. Standardize messaging for the output types.
> Right now certain kinds of messaging is presented differently for an output
> type. For example, if I issue an api command that doesn't exist it displays
> a generic error message, regardless of the output type selected. Ideally,
> all output would be in the specified format.
>
Oh man, that would be just great! Pl. share your patch.
>
> I have the first two working and am planning on implementing the others as
> I flesh them out. I will submit a patch when I feel it is ready. Any early
> feedback on whether these changes will be useful to others is appreciated.
>
You can submit patches as you finish them, don't wait till all of 5 things
are done. I can help review them and merge them.
Thanks for your proposal and sharing them.
Cheers.
> Justin
>
[ACS41][QA] Unassigned Critical Upgrade defects
Hi, Wanted to check if anyone is interested to pick up the following upgrade defects. Once upgrade testing is done, we would get a little closer to 4.1 RC. CLOUDSTACK-1839 Upgrade 4.0 -> 4.1 - Upgraded DB has lot more keys and indexes for many tables compare to the fresh installed 4.1 DB. CLOUDSTACK-1856 Upgrade 4.0 -> 4.1 - Fresh install of 4.1 has 3 parameters missing in db. Properties compared to an upgraded 4.0 set up. Thanks /Sudha
Re: [DISCUSS] git rebase vs git merge in your feature branch?
Hi, On 03/30/2013 10:03 PM, John Burwell wrote: Alex, It seems appropriate to me to use both rebase and squashed commits. To my way of thinking, we should rebase when syncing features branches with master (or the eventual target branch) to keep the revision history of the eventual patch as concise as possible. We should merge from feature branches to master (or the appropriate target branch) using a squashed commit to properly record the history if adding the feature to the branch in a coherent manner. +1, with the note that it might be useful to squash the feature branch first to make life a bit easier. So you don't get all these "short fix commits" in the master branch. Features should be merged in cleanly so they can be traced back. Wido Those are my thoughts, -John On Mar 30, 2013, at 11:21 AM, Alex Huang wrote: Dave and I have talked on IRC at one point about this. We both thought feature branch merges should come in as a squashed commit because it's easier to see exactly what the changes that merge branch brought in were and easier to revert. Something to consider when talking about this. --Alex -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Friday, March 29, 2013 4:36 PM To: dev@cloudstack.apache.org Subject: [DISCUSS] git rebase vs git merge in your feature branch? Hi all, I am trying to review some feature branches, when I see merge requests coming from mailing list, one thing that makes code review almost unrealistic is that, developers tend to use "git merge" to master branch whenever rebase is needed. I don't know other people really do review feature branch or not, if so, how to review a feature branch, with several "merge branch "master"" on the feature branch. I really don't find a better way to do that. If, all we use "git rebase" to master branch, then the code review will be much easier, at least, what kind of commits you did on the feature branch can be easily identified. For example, I worked on storage_refactor branch for a few months, with a lot of changes, before sending out merge request, there are only less than 10 commits on the branch, reviewer can use "git diff since..HEAD" to get all the changes. Should we advocate "git rebase" in https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git?
Re: [DISCUSS] git rebase vs git merge in your feature branch?
Wido, I intended my recommendation to be that the commit merged to master be squashed. Thanks, -John On Mar 31, 2013, at 6:55 AM, Wido den Hollander wrote: > Hi, > > On 03/30/2013 10:03 PM, John Burwell wrote: >> Alex, >> >> It seems appropriate to me to use both rebase and squashed commits. >> To my way of thinking, we should rebase when syncing features branches >> with master (or the eventual target branch) to keep the revision >> history of the eventual patch as concise as possible. We should merge >> from feature branches to master (or the appropriate target branch) >> using a squashed commit to properly record the history if adding the >> feature to the branch in a coherent manner. > > +1, with the note that it might be useful to squash the feature branch first > to make life a bit easier. > > So you don't get all these "short fix commits" in the master branch. > > Features should be merged in cleanly so they can be traced back. > > Wido > >> Those are my thoughts, >> -John >> >> >> >> On Mar 30, 2013, at 11:21 AM, Alex Huang wrote: >> >>> Dave and I have talked on IRC at one point about this. We both thought >>> feature branch merges should come in as a squashed commit because it's >>> easier to see exactly what the changes that merge branch brought in were >>> and easier to revert. Something to consider when talking about this. >>> >>> --Alex >>> -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Friday, March 29, 2013 4:36 PM To: dev@cloudstack.apache.org Subject: [DISCUSS] git rebase vs git merge in your feature branch? Hi all, I am trying to review some feature branches, when I see merge requests coming from mailing list, one thing that makes code review almost unrealistic is that, developers tend to use "git merge" to master branch whenever rebase is needed. I don't know other people really do review feature branch or not, if so, how to review a feature branch, with several "merge branch "master"" on the feature branch. I really don't find a better way to do that. If, all we use "git rebase" to master branch, then the code review will be much easier, at least, what kind of commits you did on the feature branch can be easily identified. For example, I worked on storage_refactor branch for a few months, with a lot of changes, before sending out merge request, there are only less than 10 commits on the branch, reviewer can use "git diff since..HEAD" to get all the changes. Should we advocate "git rebase" in https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git?
Re: Review Request: 4.1 deb packaging tomcat fixes
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9714/#review18567 --- Ship it! Ship It! - Wido den Hollander On March 2, 2013, 11:34 p.m., Noa Resare wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/9714/ > --- > > (Updated March 2, 2013, 11:34 p.m.) > > > Review request for cloudstack and Wido den Hollander. > > > Description > --- > > Changes isolated to the deb package build files, to fix > failure to start management server from deb built packages > > * Adds the tomcat6 bootstrap jar to outer classpath > * Removes install of cloud-server-4.1.0-SNAPSHOT.jar > in /usr/share/cloudstack-management/lib. This causes > /usr/share/cloudstack-management structure to be in the > way tomcat expects it to > * Update paths to logfiles, which restores log4j functionality > > CLOUDSTACK-1490: 4.1 deb management fails to start > > > This addresses bug CLOUDSTACK-1490. > > > Diffs > - > > debian/rules ba9056e > packaging/debian/replace.properties fee1def > > Diff: https://reviews.apache.org/r/9714/diff/ > > > Testing > --- > > > Thanks, > > Noa Resare > >
[ACS41][PACKAGING] Fixes from master into 4.1
Hello, I've been working on the Deb packaging today and I've committed some stuff into the 4.1 branch as well. All fixes first went into master and I did one big commit (11892d34d7ec0e37e3b5cf568a2a30d4be23590f) into 4.1 and cherry-picked some other. Since this doesn't touch any code of CloudStack I felt safe to do so without going through the review process first. Wido
Re: [DISCUSS] git rebase vs git merge in your feature branch?
I've been doing a rebase of my branch ever since this thread started and ended up in quite a lot of hell with merge conflicts. Perhaps I shouldn't have done it on a branch that I was doing merges with. So I want to understand the workflow of the rebase. Is it something like this: So I want to work on feature: 1. git co -b featureBranch 2. make my commits on day1 locally and push to remote/origin (?) 3. make my commits on day2 locally and push to remote/origin 4. decide to see the latest on master so do a git rebase master (resolve conflicts here) 5. make more changes to featureBranch on day3 and push to remote/origin 6. send in a squashed merge request for merging with master. How does this work if multiple people want to work on the aforementioned featureBranch? Does it work out this easily with everyone rebasing at will? If the fuss is about cleaner merge history then merge --no-ff will skip those annoying merge commits. I also find it easier to review the feature branch in logical chunks rather than one large patch. PS: rerere made the rebase conflicts easier but I wouldn't trust that with code I haven't touched. -- Prasanna.,
Re: [PROPOSAL] EIP across zones
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? --David
RE: [DISCUSS] git rebase vs git merge in your feature branch?
John, I was only referring to the conversation David and I had on IRC. Agreed that in this thread we should clearly define both sides for others to follow. --Alex > -Original Message- > From: John Burwell [mailto:jburw...@basho.com] > Sent: Saturday, March 30, 2013 6:01 PM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] git rebase vs git merge in your feature branch? > > Alex, > > I think we need concern ourselves with both to maximize the clarity of the > history that will eventually be merged into master. Therefore, we need to > make sure that the master to feature branch syncs are done properly as well. > > Thanks, > -John > > > On Mar 30, 2013, at 5:07 PM, Alex Huang wrote: > > > +1. I think we're specifically talking about merging into master, not > > syncing > from master. > > > > --Alex > > > >> -Original Message- > >> From: John Burwell [mailto:jburw...@basho.com] > >> Sent: Saturday, March 30, 2013 2:04 PM > >> To: dev@cloudstack.apache.org > >> Subject: Re: [DISCUSS] git rebase vs git merge in your feature branch? > >> > >> Alex, > >> > >> It seems appropriate to me to use both rebase and squashed commits. > >> To my way of thinking, we should rebase when syncing features > >> branches with master (or the eventual target branch) to keep the > >> revision history of the eventual patch as concise as possible. We > >> should merge from feature branches to master (or the appropriate > >> target branch) using a squashed commit to properly record the history > >> if adding the feature to the branch in a coherent manner. > >> > >> Those are my thoughts, > >> -John > >> > >> > >> > >> On Mar 30, 2013, at 11:21 AM, Alex Huang > wrote: > >> > >>> Dave and I have talked on IRC at one point about this. We both > >>> thought > >> feature branch merges should come in as a squashed commit because > >> it's easier to see exactly what the changes that merge branch brought > >> in were and easier to revert. Something to consider when talking about > this. > >>> > >>> --Alex > >>> > -Original Message- > From: Edison Su [mailto:edison...@citrix.com] > Sent: Friday, March 29, 2013 4:36 PM > To: dev@cloudstack.apache.org > Subject: [DISCUSS] git rebase vs git merge in your feature branch? > > Hi all, > I am trying to review some feature branches, when I see merge > requests coming from mailing list, one thing that makes code review > almost unrealistic is that, developers tend to use "git merge" to > master branch whenever rebase is needed. I don't know other people > really do review feature branch or not, if so, how to review a > feature branch, with several "merge branch "master"" on the > feature > >> branch. I really don't find a better way to do that. > If, all we use "git rebase" to master branch, then the code > review will be much easier, at least, what kind of commits you did > on the feature branch can be easily identified. For example, I > worked on storage_refactor branch for a few months, with a lot of > changes, before sending out merge request, there are only less than > 10 commits on the branch, reviewer can use "git diff since..HEAD" > to get all the > >> changes. > Should we advocate "git rebase" in > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git?
Re: [DOCS] Can't build Japanese docs
Hi Sebastien, Yes, I could build it w/o any problems... Could you show us your error message? On Sat, Mar 30, 2013 at 11:03 PM, Hiroaki Kawai wrote: > > > 2013/03/29 19:28、Sebastien Goasguen のメッセージ: > >> > >> -snip- > >>> I ended fixing it in remove-vpx.xml , the tags need to be on a > new line… > >> -snip- > >> > >> That's strange. I could successfully run publican. As it is an xml, > >> new line should not matter... > >> > >> What I did: > >> cd docs > >> tx pull -l ja_JP > >> publican build --formats xml --langs ja_JP \ > >> --config publican-installation.cfg > > > > ah yes, but --formats=pdf was failing. Should have been more precise in > the bug report. > > Humm... That's strange again. I could successfully generate PDF, too on > Fedora. > > I did: > tx pull -l ja_JP > mv ja_JP ja-JP > publican build --formats pdf --langs ja-JP --config > publican-installation.cfg > > The reason of mv is that publican supports ja-JP not ja_JP. > # See publican document about language code. > ## fop will use the value. > -- 千葉 豪 Go Chiba E-mail:go.ch...@gmail.com
RE: [PROPOSAL][CLOUDSTACK-768] ACL on private gateway
Thanks for the commnets. I will consider the ACL deny rules and update the FS. Thanks, Jayapal > -Original Message- > From: Chiradeep Vittal > Sent: Saturday, March 30, 2013 3:49 AM > To: dev@cloudstack.apache.org > Cc: Jayapal Reddy Uradi; Abhinandan Prateek; Kishan Kavala > Subject: Re: [PROPOSAL][CLOUDSTACK-768] ACL on private gateway > > This depends on the changes proposed in the ACL deny rules feature. Can > you re-word taking into account the new proposed APIs? > > On 3/28/13 12:46 AM, "Abhinandan Prateek" > > wrote: > > >+1, thanks for proposing and working on this feature. > > > >On 28/03/13 11:32 AM, "Jayapal Reddy Uradi" > > wrote: > > > >>I would like to propose the new feature ACL on private gateway. > >>This feature is sub feature of the nTier 2.0 apps. > >> > >>Currently we do not have way to control the traffic on the private > >>gateway. > >>Using this feature we can configure the ingress/egress ACL on the > >>private gateway. > >> > >> > >>Jira Id: > >>https://issues.apache.org/jira/browse/CLOUDSTACK-768 > >> > >>FS: > >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/ACLs+on+priv > ate > >>+GW > >> > >>Please provide your comments on the above FS. > >> > >>Thanks, > >>Jayapal > >> > >
RE: [PROPOSAL][CLOUDSTACK-779] Egress firewall rules for SRX
Thanks for the comments Chiradeep. I will update the rule name. Thanks, Jayapal > -Original Message- > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] > Sent: Saturday, March 30, 2013 4:19 AM > To: dev@cloudstack.apache.org > Subject: Re: [PROPOSAL][CLOUDSTACK-779] Egress firewall rules for SRX > > LGTM. > Only thing I'd be careful of the length of the policy name. > Note that the networkid is long, so you could end up with a policy name > egress-trust-untrust-1234567890123. Perhaps e-t-u- > > > > On 3/28/13 8:38 AM, "Jayapal Reddy Uradi" > wrote: > > >I would like to propose the egress firewall rules feature for the > >external firewall device SRX guest network. > > > >Currently egress firewall rules is supported in the VR isolated network. > >With this feature egress firewall rules is supported in the external > >device SRX guest networks. > > > >Jira Id: > >https://issues.apache.org/jira/browse/CLOUDSTACK-779 > > > >FS: > >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Egress+firewall > + > >rul > >es+feature+support+for+external+device+Juniper+SRX > >Please let me know your comments on the above FS. > > > >Thanks, > >Jayapal
Re: Review Request: Cloudstack-1739
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10189/#review18572 --- Ship it! Ship It! - Abhinandan Prateek On March 29, 2013, 12:29 p.m., bharat kumar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/10189/ > --- > > (Updated March 29, 2013, 12:29 p.m.) > > > Review request for cloudstack and Abhinandan Prateek. > > > Description > --- > > VMs are getting 1 GB memory on KVM hypervisor ,when they are deployed with > Service Offering having RAM >=1GB and overcommit ratio is set to some value>1 > > > This addresses bug Cloudstack-1739. > > > Diffs > - > > > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java > f786f88 > > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java > c93aeeb > > Diff: https://reviews.apache.org/r/10189/diff/ > > > Testing > --- > > manual testing on master. > > > Thanks, > > bharat kumar > >
Re: cloudmonkey printing enhancements proposal
Greetings,
I am posting my first patch. I am not sure exactly how to submit a patch
but I figure I will paste it here and someone will tell me the right
method. I am keeping track of the work that I am doing and as Rohit
suggested I will update the mailing list as I progress. This first patch
adds basic JSON output with filtering. I have tested it on cloudmonkey
4.1.0-0 and 4.1.0-snapshot3 and all seems well. Comments are appreciated.
--- README ---
Added
1. display = [default|json|tabularize] has been added in the config to
replace
tabularize = [true|false]
2. tabularize is deprecated but we will still set it as "false" once the
user
removes it out of their config to avoid throwing an error. This will be
removed in the next major version.
3. display = "default" is added to the [ui] section of the config if it is
not
present.
4. You can now output JSON formatted text by setting the config display =
json
5. You can now filter text in JSON output mode. (i.e. list users
account=grudzien filter=account,id,email). Filtered output returns a
properly formatted JSON document.
Removed
1. Removed the printing of attr keys in read_config().
Deprecated
1. tabularize = [true|false] is now messaged as deprecated.
ToDo
1. Need to format empty return messages with proper JSON messaging.
2. Need to standardize JSON output messaging.
A. Add return code [Error|Success] to all calls.
B. Add called API verb.
3. Count is not decreased in results when filtering completely eliminates a
result.
4. JSON print needs to be implemented manually to support colors. Right now
json.dumps() pretty prints the output.
5. Color tagging needs to be added to JSON printing.
6. Error messages need to have proper JSON formatting.
7. Various help text has grammar or consistency errors that need fixing.
8. Make color a passable option to a command instead of a config parameter.
(i.e. list users account=grudzien color=true)
A. This will require reworking the result_filter passable argument to
the
various print methods since they only expect filter= input.
9. The API in CloudStack 4.0.1 does not all return proper JSON formatted
text.
As a result some of the JSON printing looks funny. I will get the later
versions into a lab and test them to make sure the formatting bugs are
in
newer revisions and submit them as bugs.
--- README ---
--- PATCH ---
diff -rupN cloudstack/tools/cli/cloudmonkey/cloudmonkey.py
cloudstackmodified/tools/cli/cloudmonkey/cloudmonkey.py
--- cloudstack/tools/cli/cloudmonkey/cloudmonkey.py 2013-03-31
16:58:26.0 -0500
+++ cloudstackmodified/tools/cli/cloudmonkey/cloudmonkey.py 2013-03-31
22:03:38.0 -0500
@@ -27,6 +27,7 @@ try:
import shlex
import sys
import types
+import copy
from cachemaker import loadcache, savecache, monkeycache,
splitverbsubject
from config import __version__, __description__, __projecturl__
@@ -162,6 +163,44 @@ class CloudMonkeyShell(cmd.Cmd, object):
self.monkeyprint(printer)
return PrettyTable(toprow)
+# method: print_result_json( result, result_filter )
+# parameters: result - raw results from the API call
+# result_filter - filterset
+# description: prints result as a json object
+def print_result_json(result, result_filter=None):
+tfilter = {} # temp var to hold a dict of the filters
+tresult = copy.deepcopy(result) # dupe the result to filter
+if result_filter != None:
+for res in result_filter:
+tfilter[ res ] = 1
+myresults = {}
+for okey, oval in result.iteritems():
+if isinstance( oval, dict ):
+for tkey in x:
+if tkey not in tfilter:
+try:
+del( tresult[okey][x][tkey] )
+except:
+pass
+elif isinstance( oval, list ):
+for x in range( len( oval ) ):
+if isinstance( oval[x], dict ):
+for tkey in oval[x]:
+if tkey not in tfilter:
+try:
+del( tresult[okey][x][tkey] )
+except:
+pass
+else:
+try:
+del( tresult[ okey ][ x ] )
+except:
+pass
+print json.dumps(tresult,
+ sort_keys=True,
+ indent=2,
+ separators=(',', ': '))
+
def print_res
Re: [PROPOSAL] EIP across zones
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 >
Re: Review Request: Added / to the end_point of default local region. UI expects / while switching to other regions using single sign-on
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10059/#review18573 --- Ship it! Ship It! - Abhinandan Prateek On March 21, 2013, 11:19 a.m., Kishan Kavala wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/10059/ > --- > > (Updated March 21, 2013, 11:19 a.m.) > > > Review request for cloudstack and Chip Childers. > > > Description > --- > > Added / to the end_point of default local region. UI expects / while > switching to other regions using single sign-on > > > This addresses bug CLOUDSTACK-1065. > > > Diffs > - > > setup/db/db/schema-40to410.sql 4b7d1a7 > > Diff: https://reviews.apache.org/r/10059/diff/ > > > Testing > --- > > > Thanks, > > Kishan Kavala > >
