20090922

Agenda

Minutes

Review ACTION points from previous meeting

  • soren to add manifest files to UEC images build system for alpha6: Done
  • Daviey to update Asterisk 1.6 to RC1: In bzr and PPA, need sponsorship

ACTION: Daviey to get his Asterisk 1.6RC2 update sponsored

  • soren to publish ec2-version-query in a more appropriate place: assumed to be in hands of release team

ACTION: soren to clear out status for ec2-version-query publication

  • soren to automate updating of ec2-version-query": Blocked by previous ACTION
  • zul to ensure rabbitmq-server gets reviewed and promoted: Done
  • soren to sponsor the patch for bug 420581 and update his vmbuilder on nectarine: Done
  • ivoks to file FFe for the redhat-cluster update: Done, bug 429834

Carried-on items, for reference:

ACTION: soren to automate updating of ec2-version-query" (once publication is resolved)

ACTION: kirkland to open discussion on how to best solve the remaining configuration options on Moodle appliance

ACTION: kirkland to get help from soren and smoser on proper UEC-compatible image generation

ACTION: kirkland to discuss with niemeyer and nurmi about image store integration testing

Alpha6 postmortem analysis

Alpha6 went out last week and was globally a smoother release process than Alpha5 release. A few todo items have been identified, to be implemented for beta release:

  • Define seeds for vmbuilder to use (cjwatson, soren)
  • MIR all non-main packages used in images (smoser), in progress

This includes using euca2ools, which in the latest version is ec2-interface compatible.

ACTION: soren to update to latest euca2ools

  • Publish ec2-version-query in a appropriate place (soren)
  • Automate image publishing (smoser)
  • Add build toolchain version numbers to manifests (soren)

ACTION: soren to add image-generation-toolchain version numbers to manifests

Roadmap review: UEC/EC2 images bugs

The karmic kernel used in the Alpha6 images turned out very good. The only issue reported about it is a few missing config options (bug 428692) and lack of modules (bug 429169).

The most blocking issues in those lists are the MIR bugs since they don't strictly depend on the team and might raise last-minute extra work.

ACTION: zul to follow up on the UEC/EC2 packages MIR status

A bug needs to be filed about the fact that the images include unsupported packages, and targeted to beta.

ACTION: smoser to file one bug for the fact that the images include unsupported packages

Roadmap review: Packaging and integration of Eucalyptus 1.6

ttx performed some feature/usability testing on the Cluster install side that uncovered multiple issues preventing autoregistering of components to work properly. The blocking issue is that it is no longer possible to register using "localhost", the external IP addresses must be used instead (as they will be passed to other components), see bug 434651. This might involve asking the user for the cluster's user *and* node facing IPs. euca_conf should also support for forcing local copy of keys (bug 434651).

erichammond asked about euca2ools having to provide ec2-* links to the euca-* commands. At this point this is still under discussion. That discussion needs to happen somewhere, so a bug will be filed to support it.

ACTION: ttx to file bug about providing ec2-* command names which call euca2ools

Roadmap review: Virtual appliance

kirkland reported a slowdown in appliance creation last week, as other priorities kicked in. He encountered some issues creating the images, mostly related to vmbuilder and debconf questions. Several community members contacted him to propose their own VM appliances and appliance builders. mdz said that the reference appliance must be produced this week. We need a fully reproducible build system but producing a reference appliance to exercise UEC and the image store is more urgent. mdz will take the opportunity of being at LinuxCon with kirkland to discuss this more.

ACTION: mdz to sync with kirkland on Virtual appliance status

On the image store side things seem to be under control, with niemeyer pushing last fixes and mathiaz packaging them.

Assigned and to-be-assigned bugs

Review of the bug list raised the following remarks:

  • cjwatson considers himself almost entirely done with the eucalyptus tasks that were assigned to him
  • nurmi mentioned potential need for a few more bits in the init script to take into account /etc/eucalyptus/installer-cc.conf and will follow up with filing a bug if necessary
  • soren has a lot of bugs assigned, ttx will reassign a few to himself
  • mdz noticed that wishlist bugs should be omitted from that list unless they're targeted

ACTION: ttx to poke QA team about omitting untargeted wishlist bugs from the buglist and add something to those pages which tell you who to contact about them

Weekly SRU review

Most bugs in the recently-fixed bug list pertain to karmic only, so nothing stands out as SRU-worthy. No nominations this week.

On the list of accepted bugs with an assignee, zul said most of them are now waiting to be accepted into *-proposed. mathiaz said we should start using bzr branches to handle the SRU process, and wanted to involve sbeattie in the process.

ACTION: mathiaz to involve sbeattie in the Weekly SRU review process

Open Discussion

erichammond said he still can't update importance on any ec2-images bugs, as he is not a member of bugcontrol yet. mdz fixed it.

Agree on next meeting date and time

Next meeting will be on Tuesday, September 29th at 15:00 UTC in #ubuntu-meeting.

Soren should soon start a discussion about moving the meeting to another time, as the extended duration of the meeting doesn't fit "people in CET with families" constraints.

Log

[16:03] <ttx> #startmeeting
[16:03] <MootBot> Meeting started at 10:03. The chair is ttx.
[16:03] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:03] <ttx> Agenda is at https://wiki.ubuntu.com/ServerTeam/Meeting
[16:03] <ttx> [TOPIC] Review ACTION points from previous meeting
[16:03] <MootBot> New Topic:  Review ACTION points from previous meeting
[16:03] <nijaba> o/
[16:03] <ttx> ACTION: soren to add manifest files to UEC images build system for alpha6
[16:04] <soren> Done.
[16:04] <ttx> ACTION: Daviey to update Asterisk 1.6 to RC1
[16:04] <Daviey> In bzr and PPA, need sponsorhsip
[16:04] <Daviey> that is RC2 now :)
[16:04] <ttx> bug # ?
[16:04] <Daviey> ttx: sponsorship via prodding
[16:05] <ttx> Daviey: ok.
[16:05] <ttx> [ACTION] Daviey to get his Asterisk 1.6RC2 update sponsored
[16:05] <MootBot> ACTION received:  Daviey to get his Asterisk 1.6RC2 update sponsored
[16:05] <Daviey> (it's also NOW free sofware FWIW) :)
[16:05] <ttx> ACTION: soren to publish ec2-version-query in a more appropriate place
[16:06] <soren> Uh.. I'm not completely sure, actually.
[16:06] <soren> smoser: Do you know anything about this?
[16:07] <smoser> i'm not aware of it being published in a different place, nor the status that.
[16:07]  * soren makes a note to prod someone about it.
[16:08] <ttx> [ACTION] soren to clear out status for ec2-version-query publication
[16:08] <MootBot> ACTION received:  soren to clear out status for ec2-version-query publication
[16:08] <soren> but?
[16:08] <soren> Oh, that's a new action :)
[16:08] <ttx> I suppose "ACTION: soren to automate updating of ec2-version-query" is in the same status ?
[16:08] <soren> I thought that was another action item from last meeting :)
[16:08] <soren> They're very, very closely related, yes.
[16:08] <ttx> ACTION: zul to ensure rabbitmq-server gets reviewed and promoted
[16:09] <zul> done
[16:09] <ttx> ACTION: soren to sponsor the patch for bug 420581 and update his vmbuilder on nectarine
[16:09] <ubottu> Bug 420581 on http://launchpad.net/bugs/420581 is private
[16:10] <soren> done.
[16:10] <soren> smoser: Please correct me if I'm wrong.
[16:10] <ttx> kirkland: around ?
[16:11] <ttx> I suppose not, I'll postpone hs actionsreview until next meeting
[16:11] <smoser> 420581 is fix released and verified in alpha6
[16:11] <soren> smoser: Thanks.
[16:11] <ttx> [ACTION] kirkland to open discussion on how to best solve the remaining configuration options on Moodle appliance
[16:11] <MootBot> ACTION received:  kirkland to open discussion on how to best solve the remaining configuration options on Moodle appliance
[16:11] <ttx> [ACTION] kirkland to get help from soren and smoser on proper UEC-compatible image generation
[16:11] <MootBot> ACTION received:  kirkland to get help from soren and smoser on proper UEC-compatible image generation
[16:11] <ttx> [ACTION] kirkland to discuss with niemeyer and nurmi about ImageStore integration testing
[16:11] <MootBot> ACTION received:  kirkland to discuss with niemeyer and nurmi about ImageStore integration testing
[16:11] <ttx> ACTION: ivoks to file FFe for the redhat-cluster update
[16:12] <ttx> bug 429834
[16:12] <ubottu> Launchpad bug 429834 in redhat-cluster "FFE: Please sync redhat-cluster 3.0.2-2ubuntu1 (main) from PPA" [Undecided,New] https://launchpad.net/bugs/429834
[16:13] <ttx> Hm, is syncing from PPA a common practice ? i.e. should ivoks subscribe ubuntu-archive to that bug ?
[16:13]  * soren wonders why pitti approved it, but didn't sync it.
[16:14]  * soren asks pitti
[16:14] <mdz> ttx, FYI I'm here, but not caught up enough to know what's going on, so mostly lurking :-)
[16:14] <ttx> mdz: ok :)
[16:14] <ttx> ok, let's continue in the meantime
[16:14] <ttx> [TOPIC] Alpha6 postmortem analysis
[16:14] <MootBot> New Topic:  Alpha6 postmortem analysis
[16:15]  * mathiaz waves
[16:15] <ttx> So last week was Alpha6 release, as you may already know
[16:15] <ttx> This went globally better than alpha5 but there are still things to cover for the beta release
[16:16] <ttx> * Define seeds for vmbuilder to use (soren)
[16:16] <ttx> soren: any status update on that ?
[16:16] <soren> I believe that's in cjwatson's court at the moment.
[16:17] <mdz> soren, you've provided the package list?
[16:17] <soren> mdz: No, I can make the seed myself. I've just asked cjwatson's advice as to where to put it. It's not completely transparent to me with the way it's split up now.
[16:18] <ttx> ok.
[16:18] <ttx> * MIR all non-main packages used in images (smoser)
[16:18] <smoser> working on it.
[16:18] <smoser>      ec2-init         434693 : https://wiki.ubuntu.com/MainInclusionEc2-Init
[16:18] <smoser>      euca2ools        434697 : https://wiki.ubuntu.com/MainInclusionEuca2ools
[16:18] <smoser>      python-boto      434701 : https://wiki.ubuntu.com/MainInclusionPython-Boto
[16:18] <smoser>      python-cheetah   xxxxxx : https://wiki.ubuntu.com/MainInclusionCheetah
[16:18] <smoser>      python-configobj xxxxxx : https://wiki.ubuntu.com/MainInclusionConfigobj
[16:18] <smoser>      python-m2crypto  xxxxxx : https://wiki.ubuntu.com/MainInclusionM2crypto
[16:18] <soren> mdz: kubuntu, for instance, is a separate branch. Is EC2 enough of a different product to also warrant a separate branch?
[16:18] <soren> mdz: That sort of thing.
[16:18] <ttx> smoser: is euca2ools part of it ?
[16:18] <ttx> ok
[16:18] <smoser> yes.
[16:19] <ttx> About euca2ools, a question for nurmi_ :
[16:19] <soren> IÍ„'m reasonably sure we can get rid of configobj.
[16:19] <nurmi_> ttx: shoot
[16:19] <ttx> nurmi_: you advised us to package the latest. Does it fix the 403 Forbidden TZ-related issue ?
[16:19] <ttx> bug 431847
[16:19] <ubottu> Launchpad bug 431847 in eucalyptus "Registering images gives 403 Forbidden" [High,Invalid] https://launchpad.net/bugs/431847
[16:20] <nurmi_> ttx: it certainly solves the 403 authentication failue with 'run-instances' and 'authorize/revoke'.  The timezone issue, I'll have to investigate further (having trouble reproducing it)
[16:21] <cjwatson> soren: hmm, OK, I think I sort of missed that that was in my court; I'll deal with that
[16:21] <cjwatson> or tell you how to anyway
[16:21] <ttx> nurmi_: so it solves bug 430093 ?
[16:21] <ubottu> Launchpad bug 430093 in eucalyptus "Eucalyptus "403 Forbidden" when trying to run instance" [High,Triaged] https://launchpad.net/bugs/430093
[16:21] <nurmi_> ttx: correct
[16:21] <ttx> ok, so we need to package that, at least
[16:22] <soren> cjwatson: Cool, thanks.
[16:22] <ttx> soren: do you agree on that ?
[16:22] <soren> ttx: Do you? :) You tested it, and said it didn't work. Or has it been fixed since then?
[16:22] <ttx> soren: it fixes a separate issue.
[16:23] <soren> Ok, then.
[16:23] <soren> Well, then yes.
[16:23] <soren> Let's get the latest crack :)
[16:23] <ttx> fixes bug 430093, not bug 431847
[16:23] <ubottu> Launchpad bug 430093 in eucalyptus "Eucalyptus "403 Forbidden" when trying to run instance" [High,Triaged] https://launchpad.net/bugs/430093
[16:23] <ubottu> Launchpad bug 431847 in eucalyptus "Registering images gives 403 Forbidden" [High,Invalid] https://launchpad.net/bugs/431847
[16:23] <ttx> [ACTION] soren to update to latest euca2ools
[16:23] <MootBot> ACTION received:  soren to update to latest euca2ools
[16:23] <ttx> * Publish ec2-version-query in a appropriate place -- we already talked about that one
[16:24] <ttx> * Automate image publishing (smoser)
[16:24] <soren> Right.
[16:24] <mdz> ttx, speaking of euca2ools, I'm a bit concerned that I've heard the command line syntax is not compatible with the EC2 tools
[16:24] <ttx> smoser: How does beta release come up wrt this goal ?
[16:24] <smoser> not there yet.  I actually haven't heard anything back on the ticket.
[16:25] <ttx> smoser: ping them harder
[16:25] <smoser> i think that there are several things on my plate higher than this (mainly fixing bugs for that beta release).
[16:25] <smoser> the publishing is painful, but doable manually
[16:25] <nurmi_> mdz: in the newest package, this has also been addressed
[16:25] <mdz> nurmi_, oh, excellent
[16:26] <nurmi_> mdz: there may be a few remaining inconsistencies, but the major ones were taken care of (i'll look into it and report)
[16:26] <soren> nurmi_: Oh.
[16:26] <soren> nurmi_: So it changed its own cli interface?
[16:26] <ttx> * Add build toolchain version numbers to manifests (soren)
[16:26] <mdz> nurmi_, is it worth exploring providing ec2-* pathnames so that users can use the familiar commands (and copy/paste examples)?
[16:26] <soren> ttx: Err... Toolchain versions... in the manifest? That would be wrong, wouldn't it?
[16:27] <ttx> soren: manifests were also supposed to contain version numbers for the tools used to generate the images. Last time I looked, there were only package version numbers from inside the image
[16:27] <soren> I mean... The manifest should list what's in the image, not what was used to build it.
[16:27] <soren> Oh.
[16:27] <ttx> soren: that was mdz's original request for the manifest
[16:27] <mdz> soren, both are useful
[16:27] <nurmi_> soren: the goal was to be commandline compatible, we consider inconsistencies to be incorrect behavior (had some conflicts with python getopt, originally)
[16:27] <soren> I'm slightly surprised by this. We do have that information inside the image, though.
[16:27] <mdz> I realize we don't do this for the CD images at present
[16:28] <soren> mdz: Ahah. Ok, that's what I thought.
[16:28] <mdz> but there seems to be a much closer relationship in the case of the UEC images
[16:28] <mdz> or at least they're changing more frequently
[16:28] <soren> mdz: You'd put it in the same manifest?
[16:28] <nurmi_> mdz: perhaps, although the output of the two tools can sometimes be different (errors in particular, since the tools are written in different languages)
[16:28] <mdz> soren, if bugs in the images are often resolved by changing the build tools, we should include those IMO
[16:29] <mdz> soren, whether it's the same file, or a separate file, or whatever, doesn't matter to me
[16:29] <mdz> so long as it's possible to figure out what was used
[16:29] <soren> mdz: Ok. So the entire dependency chain of VMBuilder? Everything from VMbuilder itself down to libc?
[16:29] <soren> Or just the VMBuilder revno?
[16:29] <mdz> soren, no, just vmbuilder
[16:29] <soren> Ok.
[16:30] <ttx> [ACTION] soren to add image-generation-toolchain version numbers to manifests
[16:30] <MootBot> ACTION received:  soren to add image-generation-toolchain version numbers to manifests
[16:30] <mdz> soren, this is based on my understanding that vmbuilder does more than just aggregate packages
[16:30] <smoser> soren, probably automated-ec2-builds also
[16:30] <mdz> soren, the vmbuilder command line seems relevant as well
[16:30] <soren> mdz: Right.
[16:30] <smoser> mdz, cmdline is included in the 'automated-ec2-builds' that i mentioned above.
[16:31]  * soren will come up with something.
[16:31] <ttx> Any other comment on Alpha6 ?
[16:31] <soren> Are people expecting the manifest to be machine parsable?
[16:31] <mdz> how did the kernel turn out?
[16:31] <smoser> kernel is so far very good. the only issue that I have heard anything about is the lack of modules.
[16:31] <mdz> smoser, why are we missing modules?
[16:32] <smoser> bug 428692 .
[16:32] <ubottu> Launchpad bug 428692 in ubuntu "ec2 kernel needs CONFIG_BLK_DEV_LOOP=y and other config changes" [Medium,Confirmed] https://launchpad.net/bugs/428692
[16:32] <ttx> [TOPIC] Roadmap review: UEC/EC2 images bugs
[16:32] <MootBot> New Topic:  Roadmap review: UEC/EC2 images bugs
[16:32] <ttx> since we are on them :)
[16:32] <mdz> smoser, oh, you mean missing config options (not that the modules are missing from the images)?
[16:33] <ttx> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=ec2-images
[16:33] <smoser> and bug 429169.
[16:33] <ubottu> Launchpad bug 429169 in vm-builder "ec2: Include kernel modules in AMIs" [Medium,Triaged] https://launchpad.net/bugs/429169
[16:33] <ttx> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=uec-images
[16:33] <smoser> the missing modules from the image is the second one there.  and i just tagged that as target beta. requires vmbuilder changes to get the image inside.
[16:34] <nurmi_> is there going to be a condoned kernel for use with the UEC image on UEC?
[16:34] <smoser> nurmi_, bug 429106
[16:34] <ubottu> Launchpad bug 429106 in vm-builder "kernel and initramfs should be available for uec" [Medium,New] https://launchpad.net/bugs/429106
[16:34] <ttx> smoser: how is this one going ?
[16:35] <ttx> It would sure help the process of using those images.
[16:35] <mdz> forgive my ignorance, but is it necessary to provide the kernel and initramfs separately when we're using KVM?
[16:36] <nurmi_> mdz: in eucalyptus, yes, since part of the EC2 semantic allows users to select a kernel/ramdisk at instance run time
[16:36] <mdz> smoser, why does it require vmbuilder changes? it seems like it should just be a matter of installing the appropriate kernel package inside the image
[16:36] <mdz> nurmi_, and that's implemented even for kvm instances?
[16:36] <smoser> i've not started looking at it.  it is in general fairly trivial .some changes to vmbuilder to install the latest linux-image inside and then to copy it out and re-build the initrd after modifying /etc/initramdisk/modules (initrd should have acpiphp in it)
[16:36] <nurmi_> mdz: nod, we specify the kernel/ramdisk external to the image (which KVM allows)
[16:36] <mdz> neat
[16:37] <smoser> mdz, well, given the seeds discussion, the way vmbuilder getsa list of things to include in the image requires code change to change.
[16:37] <soren> It really doesn't have to. We should move the package list out of VMBuilder.
[16:37] <soren> ...and pass it on the command line.
[16:37] <mdz> smoser, ah, I see. hopefully that will be fixed soon
[16:37] <ttx> smoser: ok, anything blocking you on those bugs ? or anything targeted for beta that will not be doable ?
[16:38] <smoser> the thing blocking them is the MIRs that i posted above (just me working on them). I presumed that MIR were absolute highest priority. anyone refute that ?
[16:39] <smoser> i do not expect that there is anything targeted for beta that shouldn't make it. i'll go through the list today.
[16:39] <mdz> smoser, the MIRs are absolutely essential, but functional bugs may be higher priority
[16:39] <mdz> can someone else help with the MIRs to free smoser to work on functional bugs?
[16:39] <zul> i can do it
[16:39] <smoser> mdz, they're almost done. at least almost all "mostly filled out and bugs submitted"
[16:40] <ttx> [ACTION] zul to follow up on the UEC/EC2 packages MIR status
[16:40] <MootBot> ACTION received:  zul to follow up on the UEC/EC2 packages MIR status
[16:40] <smoser> i've got 2 more bugs to file then we'll have the set. and I would absolutely appreciate zul improving the MIR
[16:40] <ttx> smoser: the MIR team might ask some things to be fixed before accepting them
[16:40] <smoser> i expect that.
[16:40] <ttx> smoser: so it's good if someone else can keep an eye on them.
[16:40] <smoser> yeah.
[16:41] <ttx> ok, anything else on the EC2/UEC image front ?
[16:41] <ttx> [TOPIC] Roadmap review: Packaging and integration of Eucalyptus 1.6
[16:41] <erichammond> It sounded like euca2ools had been settled on instead of Amazon's ec2-ami-tools.  Is this still planned?
[16:41] <MootBot> New Topic:  Roadmap review: Packaging and integration of Eucalyptus 1.6
[16:41] <ttx> erichammond: yes. It's necessary so that we only ship main packages in the images
[16:41] <smoser> erichammond, given the interest in all packages being in main, ew dont have an option.
[16:42] <Daviey> Isn't euca2ools incompatiable with pre 1.6?  If so, someone on karmic can't use it with jaunty Eucalyptus?
[16:42] <ttx> Daviey: that doesn't prevent you from using ec2-ami-tools
[16:42] <ttx> its just not installed by default
[16:42] <Daviey> ok, cool.
[16:42] <nurmi_> Daviey: euca2ools is compatible with eucalyptus >= 1.5.2
[16:42] <ttx> inside images.
[16:42] <smoser> and ec2-ami-tools and ec2-api-tools will remain in multiverse. a simple apt-get away.
[16:42] <ttx> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=eucalyptus
[16:43] <ttx> so I did some usability testing on the Cluster install side
[16:43] <ttx> apart from already filed bugs, autoregister of services is in pretty bad shape
[16:44] <mdz> erichammond, any concerns with that? it's important that our image is "pure" Ubuntu
[16:44] <ttx> We used to register things from initscripts with "localhost" but that's now impossible
[16:44] <ttx> bug 434593
[16:44] <ubottu> Launchpad bug 434593 in eucalyptus "Autoregister runs euca_conf with "localhost" but that is refused in 1.6~bzr808" [High,Triaged] https://launchpad.net/bugs/434593
[16:44] <erichammond> mdz: I was just wondering if there is a bug entered for this task.  I didn't see one.
[16:44] <ttx> nurmi_: we supposed it's because we should never have done that i nthe first place ?
[16:45] <ttx> The issue is, we don't really know the external address we should use for registering.
[16:45] <mdz> smoser, is there a bug open for the fact that the images include unsupported packages?
[16:45] <nurmi_> ttx: that is true - the reason we cannot use 'localhost' to register is that the ip you supply at registration time becomes the URL of the service
[16:45] <nurmi_> ttx: i.e. S3_URL in your 'eucarc' is constructed using that value
[16:46] <ttx> nurmi_: I understand
[16:46] <smoser> mdz, no. i will open one.  is a single bug acceptable or do i need to do one per package?
[16:46] <ttx> nurmi_: but I fail to see how we can provide autoregistering for the "clc+cc+walrus+sc" setup then
[16:46] <mdz> smoser, one is sufficient, but please include a list of the problematic packages, and refer to the MIR bugs for each
[16:47] <ttx> I see no foolproof way to guess that address correctly.
[16:47] <smoser> mdz, yep. thanks.
[16:47] <mdz> smoser, or specify if some other action is to be taken (e.g. exchanging ec2-api-tools for euca2ools)
[16:47] <ttx> [ACTION] smoser to file one bug for the fact that the images include unsupported packages
[16:47] <MootBot> ACTION received:  smoser to file one bug for the fact that the images include unsupported packages
[16:48] <nurmi_> ttx: i agree, in the local case.  if thes services are all installed locally, I wonder if it wouldn't be better to ask the question at install time
[16:48] <nurmi_> ttx: perhaps in the same place during install where the installer asks 'what is your cluster name?'
[16:48] <nurmi_> ttx: adding 'what is your cluster's user and node facing IP?' here would I believe be sufficient
[16:48] <ttx> nurmi_: "What will be your cluster external IP ?"
[16:49] <soren> Internal.
[16:49] <nurmi_> both :)
[16:49] <soren> For this?
[16:49] <ttx> cjwatson: comments ?
[16:50] <ttx> nurmi_: I also filed bug 434651, since we'll want to do local copy with something that doesn't resolve to localhost
[16:50] <ubottu> Launchpad bug 434651 in eucalyptus "euca_conf should support a --local flag to enforce local key copy" [Wishlist,Triaged] https://launchpad.net/bugs/434651
[16:50] <nurmi_> soren: the IP you give to '--register-walrus' will appear in eucarc as 'S3_URL', and will be sent to nodes when they need to fetch an image
[16:50] <mdz> smoser, should we update the starter's guide to use euca2ools rather than ec2-api-tools?
[16:50] <ttx> nurmi_: but I can fix that on our side, so no hurry
[16:50] <mdz> (or in addition to)
[16:50] <soren> nurmi_: Ah, right.
[16:51] <nurmi_> ttx: great, that is a nice addition, thanks
[16:51] <ttx> Another subject, BetaFreeze is Thursday
[16:51] <erichammond> mdz: Once euca2ools is installed in the image by default, so should the package which creates the ec2- symlinks.  Does that package exist yet?  Is there a bug?
[16:51] <zul> crap..
[16:51] <smoser> mdz, maybe provide alternate/duplicate info ?  if someone just wants to use an ubuntu server, it is possible that they do not have euca2ools.
[16:52] <ttx> so we won't blindly sync euclyptus upstream bugfix revisions
[16:52] <smoser> i nthat case, the ec2-api-tools serve a larger audience.
[16:52] <cjwatson> ttx: something like that seems OK, although in some cases the machine's IP may be dynamic
[16:52] <cjwatson> ttx: can we just ask for the hostname instead, as a slight insulation from that?
[16:53] <ttx> cjwatson: hostname tends to resove to 127.0.1.1, no ?
[16:53] <smoser> wait, i've missed something "the package that installs the symlinks" . I'm not aware of such a package.
[16:53] <cjwatson> ttx: that rather depends on the environment
[16:53] <smoser> and the euca2ools are not 100% compatible with ec2-{api,ami}-tools.  providing symlinks is somewhat suggesting they are.
[16:53] <mdz> smoser, I suggested earlier that we explore providing alternate pathnames (e.g. symlinks or alternatives) for the euca2ools, so they can be called using the ec2-* names
[16:54] <ttx> cjwatson: I tried to use hostname, but then autoregister would also fail with bug 434593
[16:54] <cjwatson> and isn't it better for a name to be part of the public service URL rather than an IP address?
[16:54] <ubottu> Launchpad bug 434593 in eucalyptus "Autoregister runs euca_conf with "localhost" but that is refused in 1.6~bzr808" [High,Triaged] https://launchpad.net/bugs/434593
[16:54] <mdz> smoser, nurmi_ indicated they were compatible, or at least intended to be with only minor and temporary deviations
[16:54] <soren> mdz:  I believe we decided not to, because of syntax differences.
[16:54] <soren> mdz: ...but since that's changed..
[16:54] <cjwatson> ttx: well, I think it's going to be ugly, but if you feel it's necessary, go for it
[16:54] <mdz> erichammond, it sounds like we don't have consensus yet that that is a good idea
[16:55] <ttx> cjwatson: alternative is to drop the idea of autoregistering components. Not sure how acceptable that would be
[16:55] <erichammond> mdz: Ok, we can discuss outside of the meeting.
[16:55] <cjwatson> we have to autoregister components, I think
[16:55] <nurmi_> mdz: there are a few things to consider, aside from commandline arguments
[16:55] <cjwatson> ttx: we could ask for a hostname but check that it resolves to something outside 127.0.0.0/8
[16:55] <mdz> ttx, is there a followup action recorded with regard to discussing providing ec2-* command names which call euca2ools?
[16:55] <smoser> i think if there is intent/support for making them 100% compatible, that would be wonderful.  It does put added development effort on either eucalyptus or ubuntu for maintaining that.
[16:56] <ttx> mdz: I don't think so.
[16:56] <nurmi_> mdz,erichammod: failure/fault format, and staying up-to-date with the latest EC2 functionality
[16:57] <ttx> mdz: should be filed as a bug against euca2ools and tagged uec/ec2-images
[16:58] <ttx> cjwatson: I'll think again about it and bother you again for guidance :)
[16:58] <ttx> [ACTION] ttx to file bug about providing ec2-* command names which call euca2ools
[16:58] <MootBot> ACTION received:  ttx to file bug about providing ec2-* command names which call euca2ools
[16:58] <ttx> Anything else on the Eucalyptus bugs ?
[16:59] <ttx> Are all the bugs on the list reasonably assigned and targeted ?
[16:59] <nurmi_> there is an issue with dynamic block attach/detach that I think might be unassigned
[16:59] <ttx> nurmi_: I assigned it to kirkland
[16:59] <mdz> nurmi_, good reasons to consider it, though, such as having example commands and documentation work
[16:59] <ttx> nurmi_: sounds like a kvm-qemu regression
[17:00] <ttx> I'll assume no more comments from the crowd, then
[17:00] <ttx> [TOPIC] Roadmap review: Virtual appliance
[17:00] <MootBot> New Topic:  Roadmap review: Virtual appliance
[17:00] <nurmi_> mdz: absolutely, I just want to mention those issues as things to consider before an evaluation is done
[17:00] <ttx> niemeyer and kirkland aren't around afaict
[17:01] <mdz> nurmi_, agreed
[17:01] <mdz> nurmi_, or rather, *while* the evaluation is done :-)
[17:01] <ttx> mdz: I'm slightly concerned about the state of this, as I haven't seen much progress since last week
[17:01] <mdz> ttx, kirkland is here at linuxcon, is there something I should check with him?
[17:01] <ttx> mdz: definitely. See my status email from end of last week and his activity report
[17:01] <nijaba> niemeyer is in vacation for the week
[17:02] <mdz> ttx, ok, I'll take an action
[17:02] <ttx> [ACTION] mdz to sync with kirkland on Virtual appliance status
[17:02] <MootBot> ACTION received:  mdz to sync with kirkland on Virtual appliance status
[17:02] <ttx> I think the server-side is under control, with mathiaz pushing fixes from niemeyer
[17:02] <nurmi_> ttx,soren: one more euca issue, happy to discuss later time permitting
[17:03] <ttx> nurmi_: on #ubuntu-server just after the meeting ?
[17:03] <nurmi_> ttx,soren: regarding MANAGED mode instead of SYSTEM mode, is the transition on the table for beta?
[17:03] <nurmi_> ttx: sounds good :)
[17:03] <kirkland> mdz: ttx: i'm here now
[17:03] <soren> nurmi_: !??!? that was done weeks ago?
[17:03] <ttx> kirkland: yo :)
[17:03] <soren> nurmi_: Surely?
[17:03] <nurmi_> soren: really?
[17:03]  * nurmi_ eyes himself warily
[17:04] <ttx> kirkland: anything to add ? I think its more a question of objectives and priorities, right now, so discussing it with mdz should help ?
[17:04] <kirkland> ttx: right, sure, my appliance creation slowed last week, as I was helping test the ISOs and fix eucalyptus bugs
[17:05] <kirkland> ttx: i hit a few speed bumps creating the images, related to vmbuilder, and debconf
[17:05] <soren> nurmi_: http://bazaar.launchpad.net/~ubuntu-core-dev/eucalyptus/ubuntu/revision/542
[17:05] <kirkland> ttx: i have been pinged by several people in the community, saying that they have vm appliances and appliance builders that they would like us to consider
[17:06] <mdz> kirkland, what is your ETA for having a working appliance image we can test?
[17:06] <nurmi_> soren: the CC and NC eucalyptus.conf files on my alpha6 default install are both set to SYSTEM
[17:06] <soren> I'm not convinced using a completely different, unknown tool to create appliances is a stellar idea two days before betafreeze.
[17:07] <soren> nurmi_: What's in installer-cc.conf?
[17:07] <kirkland> mdz: if i fall back to "rebundling", perhaps this week; i don't really like that though, as its not very reproducible
[17:07] <mdz> kirkland, we need something this week
[17:07] <cjwatson> what's the problem with debconf?
[17:07] <kirkland> mdz: if we're trying to produce a "reference appliance", i'd think the process of creating the image is as important as the image itself
[17:08] <nurmi_> soren: ah, cool! I did not know about this
[17:08] <kirkland> cjwatson: couple of things, i'll poke you in -devel
[17:08] <ttx> cjwatson: the Moodle appliance kirkland was working on is asking a debconf "what is your FQDN" question that we have trouble to find a sane default for
[17:08] <soren> nurmi_: Good point about the NC, though.
[17:09] <cjwatson> oh, so not actually a debconf bug, a use-of-debconf problem
[17:09] <kirkland> ttx: it goes deeper than that
[17:09] <kirkland> cjwatson: right, use-of-debconf + preseeding (sort of) issue
[17:10] <ttx> ok, we should move on
[17:10] <nijaba> kirkland: can't this be set to some dummy value at build time, and then configured using a firstlogin script?
[17:10] <kirkland> nijaba: yes, that's what the first rev of my image did; requires the user login via ssh once
[17:10] <kirkland> nijaba: mdz asked me to try and avoid that
[17:11] <nijaba> ok
[17:11] <ttx> kirkland: mdz should sync with you to discuss what, when and priorities
[17:11] <ttx> [TOPIC] Roadmap review: Other specs from the Roadmap
[17:11] <MootBot> New Topic:  Roadmap review: Other specs from the Roadmap
[17:11] <mdz> kirkland, the purpose of the reference appliance is to exercise UEC and the image store, more than the build tools
[17:12] <mdz> kirkland, we need to get to a fully reproducible build, but we don't need to start there, and it's blocking other work
[17:12] <ttx> anyone has anything to mention about the state of other specs from the Roadmap ?
[17:13]  * ttx tries to fit into 90 minutes
[17:13] <ttx> ok then
[17:13] <ttx> [TOPIC] Assigned and to-be-assigned bugs
[17:13] <MootBot> New Topic:  Assigned and to-be-assigned bugs
[17:14] <ttx> http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
[17:14] <MootBot> LINK received:  http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
[17:14] <cjwatson> at this point I'm considering myself almost entirely done with the eucalyptus stuff that was assigned to me, with the exception of one or two more bugs
[17:14] <cjwatson> if this assumption breaks anyone, please let me know
[17:14] <ttx> No bugs assigned to the team...
[17:14] <nurmi_> cjwatson: we may need a few more bits in the init script to take into account /etc/eucalyptus/installer-cc.conf
[17:15] <mdz> we should probably omit wishlist bugs from that list unless they're targeted
[17:15] <ttx> Most of the bugs were covered in the previous lists...
[17:15] <ttx> mdz: who can change that ?
[17:16] <mdz> ttx, the QA team
[17:16] <cjwatson> nurmi_: I noticed somebody had changed eucalyptus.conf to source installer-cc.conf itself, so wouldn't that cover that?
[17:16] <ttx> [ACTION] ttx to poke QA team about omitting untargeted wishlist bugs from the buglist
[17:16] <MootBot> ACTION received:  ttx to poke QA team about omitting untargeted wishlist bugs from the buglist
[17:16] <nurmi_> cjwatson: no, that file is read directly from the CC
[17:17] <nurmi_> cjwatson: at least, the networking parts are
[17:17] <ttx> anything in that list anyone feels uncomfortable with ?
[17:18] <mdz> ttx, so long as you're prodding the QA team, please ask them to add something to those pages which tell you who to contact about them :-)
[17:18] <mdz> smoser, you have one bug assigned to you which is New; please update the status
[17:18] <ttx> mdz: heh
[17:19] <ttx> Moving on to...
[17:19] <cjwatson> nurmi_: I think I must be missing something; but I was hoping that one of the server team could clear up loose ends there, since I'm not all that well-placed for detailed testing
[17:19] <ttx> [TOPIC] Weekly SRU review
[17:19] <MootBot> New Topic:  Weekly SRU review
[17:19] <mdz> ttx, soren's bug list is long, and you don't seem to have any. could you take some of his perhaps?
[17:19] <ttx> The list at http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html contains recently fixed bugs, if there is anything worth nominating in there, please shout now
[17:20] <nurmi_> cjwatson: sure, I was thinking that this was an init script issue
[17:20] <zul> ttx: not from me alot of those bugs pertain to karmic only
[17:20] <ttx> mdz: I will assign myself the autoregister I just filed
[17:20] <ttx> and see what I can pick to reduce soren's burden
[17:21] <ttx> zul: yes.
[17:21] <ttx> No nominations this week
[17:22] <cjwatson> nurmi_: happy to look at a bug if it's filed, I was just sounding a general reduced-availability warning
[17:23] <ttx> Accepted bugs with an assignee: http://qa.ubuntu.com/reports/ubuntu-server-team/acceptedbugs.ubuntu-server.latest.html
[17:24] <ttx> Is this is no longer current, please shout
[17:24] <zul> most of those are waiting to be accepted into *-porposed
[17:24] <ttx> zul: ok, good
[17:24] <mathiaz> zul: could we start to use bzr branches?
[17:24] <zul> mathiaz: yep
[17:24] <mathiaz> ttx: I was also think about involving sbeattie in the process
[17:25] <mathiaz> ttx: to do the bzr review (last step)
[17:25] <ttx> mathiaz: sure, good idea. You'll talk to him ?
[17:25] <mathiaz> ttx: yes.
[17:25] <ttx> [ACTION] mathiaz to involve sbeattie in the Weekly SRU review process
[17:25] <MootBot> ACTION received:  mathiaz to involve sbeattie in the Weekly SRU review process
[17:25] <ttx> mdz: want to talk about Server Team Bug Workflow today ?
[17:26] <ttx> or is it too late already ?
[17:26] <mdz> ttx, I am available
[17:26] <mdz> do you mean the things we've discussed by email or something new+
[17:26] <mdz> ?
[17:27] <ttx> mdz: no, there is an agenda item about that
[17:27] <ttx> "please delay this discussion until the next meeting attended by MattZimmerman"
[17:27] <mdz> ttx, let's follow up on that by email
[17:27] <ttx> ok
[17:27] <ttx> [TOPIC] Open Discussion
[17:27] <MootBot> New Topic:  Open Discussion
[17:28] <erichammond> mdz: I still don't have the ability to update importance on any ec2-images bugs.  For the time being, is there a person I can send recommended changes to?
[17:28] <zul> im probably going to ask a FFE for dovecot and samba any objections?
[17:28] <soren> Did you not become a member of bugcontrol?
[17:29] <erichammond> soren: I don't know how launchpad works, just that the Importance is not clickable for me.
[17:29] <mdz> erichammond, smoser for now
[17:29] <mdz> erichammond, who was helping you with joining bugcontrol? bdmurray?
[17:29] <erichammond> mdz: I'd have to look that up.  I got passed around a few times.
[17:30] <ttx> Eric isn't in bugcontrol yet.
[17:30] <mdz> ttx, I asked Marjo to help him get set up
[17:30] <ttx> ok.
[17:30] <ttx> zul:  samba requires FFE ?
[17:31] <zul> 3.4.1 is in debian testing
[17:31] <ttx> I thought its a bugfix release
[17:31] <zul> yer right it doesnt according to the changelog
[17:32] <ttx> [TOPIC] Agree on next meeting date and time
[17:32] <MootBot> New Topic:  Agree on next meeting date and time
[17:32] <ttx> same time, next week, same batchannel ?
[17:32] <ttx> I'll update the page to reflect the fact that our meeting now last 90 minutes
[17:32] <ttx> lasts, even
[17:33] <ttx> ?
[17:33] <soren> I'm going to start a discussion about the meeting time real soon.
[17:33] <soren> this time is absolutely horrible for me.
[17:34] <soren> ...and I have a hunch that other people in CET with families are in the same boat.
[17:34] <soren> So, look out for an e-mail on ubuntu-server@l.u.c.
[17:34] <ttx> soren: I don't see who you're talking about
[17:34] <soren> ttx: Sure you don't :)
[17:35] <soren> Can we go now, please?
[17:35] <soren> :)
[17:35] <ttx> #endmeeting

MeetingLogs/Server/20090922 (last edited 2009-09-23 08:14:08 by lns-bzn-48f-81-56-218-246)