openstack team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Tue, Apr 12, 2011 at 3:13 AM, Thomas Goirand <thomas@xxxxxxxxxx> wrote:
> I'm not mistaking or dreaming, "bzr commit" as well. Using Git, it's not
> the case. The issue isn't to cache data, the issue is that a commit
> should *never* access any remote data, so that I could work in the train
> without connectivity, for example, and still be able to do "bzr commit".
> Only pull and push should do network accesses.

If 'bzr commit' is doing network access, its been configured to work
directly with a branch over the network, or you have a plugin that is
doing network access. The former may have been done for workflow
reasons in maintaining the trunk - but that surprises me as I thought
your project was using tarmac, where you would only push to personal
branches and the robot would test and promote branches that pass the
test suite.

The next time you observe 'bzr commit' do networking, could you grab a
'bzr info' from that tree and show it to me, or #bzr on freenode, and
we can sort out what is up.

>> We're desperately short of technical data on the slownesses reported
>> from China *specifically*.
>
> I'd be happy to help, but I'm very surprised that you didn't get reports
> from Canonical people working in Beijing or Shanghai.

Sadly no, the folk I hear about suffering are staff on-site with other
companies, and I haven't managed to get the contacts in place to
diagnose yet.


>>  - we're considering an SSL frontend CDN with a node in asia
>
> Not needed. Just get bandwidth from the correct providers (like
> twtelecom or PCCW), and it will be acceptable. Adding a cache wont help
> much if the cache is badly connected...

It wouldn't cache, just do SSL in the region; this could help in a few ways:
 - we could get bandwidth to it from twtelecom
 - it would be close enough to do ssl handshaking in ~ 1 second rather
than the many seconds you're paying at the moment
 - we would have dedicated backhaul bandwidth on it to our primary
datacentre (London) rather than depending on local ISP prioritisation.

Anyhow -
...
> Don't search: sprint is the one!!! As I'm writing this mail, it's 11pm,
> and I get 20% packet loss... And that's not even peak hours in here
> (which is between 5 and 8pm local time). I can send traceroutes with mtr
> if you like, but I believe it will be annoying reads for the readers of
> this list. Maybe we should switch to private emails?

The data about sprint is interesting; I'm going to go find the ticket
we have about performance in china and add this information to it.

Thanks!
Rob