[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GCE scripts status



On 8 April 2014 21:37, Jimmy Kaplowitz <jkaplowitz@google.com> wrote:
Great work Tomasz!

On Tue, Apr 8, 2014 at 12:27 PM, Tomasz Rybak <tomasz.rybak@post.pl> wrote:
1. I had to comment out one line configuring GRUB ttyS),
as it was giving error

The setting to configure GRUB to display in the serial console (GRUB_TERMINAL) was broken in build-debian-cloud as well. It's worth fixing at some point so that gcutil getserialportouput allows debugging GRUB issues, but it's not a blocker for either merge or adoption by the official GCE images. 

It is important that the kernel command line gets the serial console options (GRUB_CMDLINE_LINUX).

2. registering image does not work: there is some problem
with PATH when trying to call gsutil; I did not want
to hardcode gsutil and gcutil paths until we have
Debian packages for those.

I wouldn't view this as a merge blocker either. Optionally automating the gsutil and gcutil calls is a nice convenience but not actually part of the image build process; we're currently not passing --gcs-dest and --gce-project anyway, for reasons specific to our environment and multi-OS build/test/validate/publish workflow. We are of course relying on build-debian-cloud in general for the Debian builds, and will soon be relying on bootstrap-vz instead.
 
As for merge - should I first try to change my branch to new layout,
or create new branch (from the current state of the master)
and apply changes there?

I'll defer to Anders on other considerations before merge, though in my view the sooner the better.
 
- Jimmy

> I've just pushed latest commit adding missing functionalities in GCE branch: cleaning APT sources and removing Google keys, and registering image with GCE.
Sweet! Nice job!

> As for merge - should I first try to change my branch to new layout, or create new branch (from the current state of the master) and apply changes there?
If I were you I'd go for the second one. The directory layout isn't the only thing that has changed, trying to mirror all the changes in your own branch would give you massive headaches.
Back when I needed the changes from master in the dev branch I did a rebase, but having to fix the same conflicts over and over again got really annoying. I recommend a merge.

p.s.: I am sorry for your troubles, but my homegrown project structure was simply not something that resembled a normal python package and it needed to change (forgive me, I didn't know better back then :-) ).

Reply to: