18:02:36 #startmeeting 18:02:37 Meeting started Thu Dec 1 18:02:36 2011 UTC. The chair is renuka. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:38 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:49 #topic openstack volumes 18:03:18 I mainly had to raise one point,about the usage of the host flag 18:03:40 so before that, do either of you have any updates or would like to discuss anything today? 18:04:12 Nothing really from me. I've been trying to set up a cloud in house the past week or so and that's about it. 18:04:13 nope, I have no updates. stuck with integrating our stuff with keystone 18:05:14 vladimir3p: so this week or so, you mentioned you can start on the scheduler, is that still on track? 18:05:43 hope to start it 1st week of Dec (next week) 18:06:07 but only if I'll succeed to bring up our keystone :-) 18:06:52 right, keep us in the loop :) 18:07:04 #topic host flag 18:07:26 so I just wanted to ensure that everyone is aware of this... 18:07:44 so far we have been using the host flag in the code as if it is necessarily an IP address 18:08:05 recently with some upgrade work, it was proposed that it should be a GUID for a machine 18:08:18 that began to break some iscsi tests 18:08:28 i believe we have a fix here: https://review.openstack.org/#change,1982 18:08:39 #link https://review.openstack.org/#change,1982 18:09:17 let me take a look, I'm not sure if we ever experienced such issue... 18:09:46 so please keep in mind that the host flag, and therefore volume['host'] and iscsi_target['host'] may not be IP addresses and could well be some form of IDs 18:10:16 you may not have experienced it yet, because John from citrix is doing the upgrades changes... so they may not be upstream 18:10:17 hmm... volume['host'] is always a hostname, isn't it? 18:10:28 well it has been, so far 18:10:32 So forgive me for the ignorant question, but where is the coorelation made back to an IP? Assuming some link back to the database? 18:10:38 I am just pointing out that in the future it need not be 18:11:31 in that patch on gerrit, we are populating "provider location" with the details of where to find the iscsi target 18:11:46 Yes, sorry... I just read it in the change link you sent. 18:12:13 right, so the definition of "host" has been clarified now 18:12:35 ok, I see... 18:13:01 since I would most certainly have read the code assuming volume['host'] is an IP address, I wanted to make it a bit more explicit that it need not be 18:13:11 this is irrelevant for us, because we never really used it. The IP is filled up from host-specific SW we install on every host and from there we create provider_location 18:13:49 renuka, I still suppose that volume['host'] is just a hostname ... 18:14:32 last conversation I had about this change, it was decided that volume['host'] should continue to be whatever is in the host flag 18:14:45 ok 18:14:49 in fact it has always been that... i dont think this change changes it 18:14:56 let me check 18:15:52 right, it doesn't 18:16:49 so whenever someone starts the services with the host flag set to something else that is not an IP address, we run the risk of misusing volume['host'] if we are not careful 18:17:32 unless this is set to default value, which is hostname 18:17:37 and supposed to be unique 18:18:18 it will be unique in either case...we just don't have a guarantee that it can be used as an IP address 18:18:49 for example, with the recent changes, the iscsiadm commands were failing, because the code does a "-p volume['host']" 18:19:00 that assumes it is an IP address 18:19:08 so any such lines of code, we need to watch out for 18:20:14 renuka, just to understand ... if you override FLAGS.host with an IP address it means that on all levels (schedulers, API, etc) you are using IP and not a hostname 18:20:24 which is fine, but it is on all levels 18:20:34 yes 18:20:39 FLAGS.host is kind of "global" param for Manager 18:20:46 yes 18:20:49 it means that all compute services and others are using it 18:20:49 ok 18:21:37 this caveat does apply to any other coding that you are doing also 18:21:59 hmm... not really 18:22:10 we don't care what exactly is set in host field 18:22:18 cd vsa 18:22:18 it just should be unique 18:22:18 ls 18:22:27 sorry 18:22:30 :-) 18:22:33 #info FLAGS.host and therefore volume['host'] need not always be an IP address 18:22:45 yeah :-) 18:22:45 :) 18:23:38 ok, do we have anything else for today? 18:23:41 right, i didn't really have anything more for the meeting 18:24:05 unless you could tell me where I could find normal & stable keystone for Natty 18:24:06 Nothing here really, just trying to actually stand up instances and connect to iscsi storage. 18:24:19 (preferably in form of packages) 18:24:22 I'll be finishing my blue-print and submitting properly next week. 18:24:47 I've been using Kiall's script (which uses packages) 18:25:02 vladimir3p: I haven't installed from packages before... have you looked at devstack? not sure if they use keystone 18:25:13 aah ok 18:25:22 Trouble is I'm trying to do physical machines (multi-node) 18:25:45 Kialls script gives keystone, glance, dashboard etc. 18:26:11 Now I'm hosed though because none of the euca2ools stuff is configured.... anyway, that's going to be the rest of my week. 18:26:21 #keystone packages 18:26:37 this, for oniric http://packages.ubuntu.com/oneiric/keystone does not help? 18:27:01 yes, I've seen this one for oneiric, but we are using Natty 18:27:07 not sure if it will work 18:27:45 also, I was trying to use the latest stable/diablo branch from devstack, but it is behaving weird... the one from 1-2 weeks ago worked perfectly 18:27:49 maybe we should keep this out of the meeting and on the #openstack chat room where more people can help 18:28:05 yeah, let's finish the volume one 18:28:11 #endmeeting