Merge lp://staging/~julian-edwards/gwacl/licence-readme-etc into lp://staging/gwacl

Proposed by Julian Edwards
Status: Merged
Approved by: Julian Edwards
Approved revision: 212
Merged at revision: 209
Proposed branch: lp://staging/~julian-edwards/gwacl/licence-readme-etc
Merge into: lp://staging/gwacl
Diff against target: 202 lines (+148/-24)
3 files modified
HACKING.txt (+102/-2)
LICENSE (+16/-0)
README (+30/-22)
To merge this branch: bzr merge lp://staging/~julian-edwards/gwacl/licence-readme-etc
Reviewer Review Type Date Requested Status
Jeroen T. Vermeulen (community) Approve
Review via email: mp+177989@code.staging.launchpad.net

Commit message

Clean up of licence info and add a lot more info to HACKING and README.

To post a comment you must log in.
Revision history for this message
Jeroen T. Vermeulen (jtv) wrote :
Download full text (4.1 KiB)

Oh, this is very nice. Just the overview people will need.

A few odds and ends:

37 +Role instances are virtual machine resources. Many instances may exist in a
38 +deployment (and hence hosted service) but if there is more than one they are
39 +intended to be running the same load balanced application via the service;
40 +they must all share the same DNS entry and open endpoints.

Calling them virtual machine "resources" seems confusingly vague. Isn't a role instance essentially a virtual machine?

Also, is it really true that multiple VMs are meant to run the same application in a load-balanced configuration? My understanding was that you might just as well have different components of the same application (e.g. database, application process, httpd) running on different VMs in the same service. The wording here seems to rule that out.

Might it be more accurate to say that a hosted service exposes one application on the internet, and it may comprise multiple virtual machines for load-balancing and/or different components of the application?

Also, I wouldn't say they "must" all share the same DNS entry — they all share the same DNS entry and the same IP address, and there's no way around it. As for endpoints, they can of course have their own port mappings on that same IP address (and possibly load-balanced shared endpoints, but I never read the documentation for that part).

42 +For this reason, if you want several separate resources, you must create a
43 +separate service, deployment and role instance for each.

"Resources" again is very vague. If there are resources I want to share and ones I don't want to share, this sentence leaves me completely in the dark about what to do.

48 +Each service can only see as much of each other service as any public observer
49 +does. It's possible to place them in a private network so they are
50 +effectively on a share LAN segment with no firewall.

I think these two sentences would fit together more clearly with a "However." The second sentence is a way to escape the limitations laid out by the first, so there's a clear contrast. It's not a case where the second sentence follows naturally on the first.

52 +In Azure this is called a "virtual network". The virtual network must be
53 +defined before any services are created, and then supplied at service creation
54 +time. The virtual network can be assigned any valid networking range which
55 +becomes private to all the virtual instances defined to use it.

The "before any services are created" is a bit ambiguous, to the extent that "any services" here means "any services that will use the virtual network." How about "You can define a virtual network, and supply it when you create a service. This will attach the service to the virtual network for the service's entire lifetime." Some people dislike addressing the reader directly, but it beats having most of the text in passive voice.

Another thing that may puzzle the unschooled reader is "any valid network range which becomes private to all the virtual instances defined to use it." (Where "virtual instances" should probably be "virtual machines"). It reads as if something happens t...

Read more...

review: Approve
212. By Julian Edwards

tweaks as per review

Revision history for this message
Julian Edwards (julian-edwards) wrote :

Ok I've tweaked things. Not always exactly as you want because you like dangling prepositions and they are generally considered bad form :)

Thanks for the review!

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches

to all changes: