13:00:30 <mvollmer> #startmeeting! 13:00:31 <zodbot> Meeting started Mon Oct 5 13:00:30 2015 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:41 <mvollmer> .hello mvo 13:00:42 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com> 13:03:03 <andreasn> .hello andreasn 13:03:04 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com> 13:04:19 <mvollmer> petervo, around? 13:04:59 <mvollmer> let's start 13:05:02 <mvollmer> #topic Agenda 13:05:08 <mvollmer> * timesync 13:05:25 <andreasn> *iSCSI 13:05:52 <andreasn> I would love to talk SELinux, but I think dperpeet isn't around yet 13:06:01 <andreasn> so I'll grab him later tonight or tomorrow 13:06:08 <mvollmer> right 13:06:19 <mvollmer> then it's a quick meeting. :-) 13:06:31 <mvollmer> #topic timesync 13:06:38 <mvollmer> so I started hacking on this. 13:07:00 <mvollmer> the config API is a typical "drop your files here" setup. 13:07:26 <mvollmer> also, individual network configuration bits can contribute NTP servers. 13:07:39 <mvollmer> which means it is not easy to manage the whole picture. 13:07:49 <andreasn> individual network conf? how? 13:08:06 <mvollmer> the *.network files used by networkd 13:08:10 <andreasn> ah, I see 13:08:29 <andreasn> are these attached to specific connections? 13:08:51 <mvollmer> so we can, in a straightforward way, manage our own list of NTP servers, which will be used in addition to the others. 13:08:56 <mvollmer> wherever they come from. 13:09:26 <mvollmer> this is enought to make things work 13:09:32 <andreasn> all right 13:09:42 <mvollmer> but not enough for control freaks like the original user story 13:09:59 <mvollmer> I have changed that user story... 13:10:28 <mvollmer> https://github.com/cockpit-project/cockpit/wiki/Feature:-Time-Sync-Configuration/_compare/561bcbc8f4357d3dedfb2191187dd4553d0c56fa...0caf597e90205ef3048ccf7ac4c6be4dc00ade3e 13:10:43 <andreasn> #info https://github.com/cockpit-project/cockpit/wiki/Feature:-Time-Sync-Configuration 13:11:09 <mvollmer> other than that, this should be ready soonish 13:11:24 <andreasn> great to hear! 13:11:31 <mvollmer> timesyncd is a bit silent about errors, so things don't work until they magically do 13:11:36 <mvollmer> like with NTP in general 13:11:54 <andreasn> changes to the user story makes sense 13:12:11 <andreasn> that's how it is I guess 13:12:19 <andreasn> re the errors 13:12:21 <mvollmer> we can show the timesync status in the dialog, maybe 13:13:14 <andreasn> what status could that be? 13:13:42 <mvollmer> "Using Time Server 66.135.44.92:123 (0.fedora.pool.ntp.org)." 13:13:44 <mvollmer> just a string 13:14:03 <andreasn> ah, yeah 13:14:09 <andreasn> that we get from networkd? 13:14:34 <mvollmer> we can combine that with timedatectl "NTP synchronized" 13:14:46 <andreasn> sure 13:16:00 <github> [cockpit] rbuj opened pull request #2902: add Catalan (master...catalan) http://git.io/vcy7H 13:16:24 <andreasn> do you have a public branch already? 13:16:29 <mvollmer> okay, more about this later then 13:17:05 <mvollmer> next? 13:17:16 <andreasn> sure 13:17:17 <mvollmer> #topic iSCSI 13:17:41 <mvollmer> we got feedback from fabiand, thanks! 13:17:59 <andreasn> yes, very useful! 13:18:00 <fabiand> mvollmer, no problem at all! 13:18:01 <mvollmer> biggest item is probably "multi select" 13:18:28 <andreasn> yeah, and as I understood, that was because of multipath 13:18:54 <mvollmer> ahh, I see 13:18:55 <fabiand> actually for mpath and for convenience if you want to attach multiple targets (but the latter is probably not that important for now) 13:19:06 <fabiand> for mpath the "consolidation" appaorach might be a good thing .. 13:19:07 <mvollmer> for convenience with multipath, then? 13:19:32 <mvollmer> can we identify the mpath setup before login? 13:19:41 <fabiand> for mpath it really makes sense, because you - rather cockpit - would directly attach all paths for a specific disk .. 13:19:47 <fabiand> mvollmer, no 13:19:55 <fabiand> but you can identify it once you see the targets 13:20:07 <mvollmer> what is a target again? 13:20:14 <fabiand> target== disk 13:20:18 <mvollmer> right 13:20:40 <mvollmer> but that's too late to help with convenience in the "Add portal/node/whatever" dialog. 13:20:45 <fabiand> so, when you see multiple disks in the same portal with the same serial, then it is an mpath device 13:21:10 <mvollmer> yes, we should handle that already, since recently. 13:21:16 <fabiand> really!? 13:21:19 <mvollmer> in the general case, not just iscsi. 13:21:23 <fabiand> right 13:21:25 <mvollmer> is there something special about iscsi? 13:21:31 <fabiand> yes .. 13:21:37 <mvollmer> *sigh* 13:21:40 <fabiand> :) 13:21:49 <andreasn> haha 13:21:51 <andreasn> :) 13:21:53 <fabiand> mvollmer, in the iscsi case each path will appear as an individual target 13:22:14 <fabiand> so, you need to connect all targets (which represent paths to the same disk) before you can join them into an mpath device 13:22:19 <mvollmer> target == block device, right? 13:22:22 <fabiand> yep 13:22:35 <mvollmer> how do I connect them? 13:22:48 <mvollmer> ohh, I see, sorry. 13:22:48 <fabiand> so, it would be ideal if the target dialog could merge multiple disks into one logical mpath device, if it sees that they share the same serial 13:22:54 <fabiand> mvollmer, :) 13:23:09 <mvollmer> there is no target dialog 13:23:17 <fabiand> let me check how it is called 13:23:44 <mvollmer> you said target == disk, so let's never mention target again 13:23:50 <fabiand> :D 13:24:35 <fabiand> "Available targets on 127.0.0.1" - that is the dialog where disks with the same serial should be "grouped" 13:24:52 <mvollmer> does that dialog show disks? 13:25:11 <fabiand> yes 13:25:13 <mvollmer> i thought it shows something one level above disks 13:25:15 <fabiand> iqn.2003-01.org.linux-iscsi.mvollmer-cockpit-iscsi-demo.x8664:sn.eeb23e67ee13 127.0.0.1 3260 13:25:25 <fabiand> no, that is portals 13:25:25 <mvollmer> that's one disk? 13:25:30 <fabiand> oh 13:25:31 <fabiand> wait 13:25:47 <fabiand> no, all right .. 13:25:52 <fabiand> portal has many disks 13:26:01 <fabiand> portal = first dialog (iqn, user/pw) 13:26:12 <fabiand> disks (targets) = second dialog 13:26:23 <fabiand> optional third dialog = auth for target 13:26:37 <andreasn> fabiand: the server I tested with earlier had a multipath, right? 13:26:49 <andreasn> maybe mvollmer could test with that one as well 13:26:53 <fabiand> andreasn, the one which fails to connect? yes 13:27:00 <andreasn> yup 13:27:03 <fabiand> yep 13:27:37 <andreasn> because in that case the disks had different addresses, one was x.x.x.12 and the other x.x.x.13 13:27:55 <mvollmer> fabiand, the first dialog runs iscsiadm --mode discovery and uses the result to ppopulate the second dialog. 13:28:30 <mvollmer> can we use the result of --mode discovery to make gropus that should be logged in at the same time? 13:28:33 <fabiand> mvollmer, right - you point discovery to a portal 13:28:55 <fabiand> mvollmer, yes 13:29:18 <mvollmer> how to we make those groups? 13:29:22 <mvollmer> *do 13:29:30 <fabiand> mvollmer, we group them by serial 13:29:45 <mvollmer> the results of iscsiadm --mode discovery does not contain serials. 13:29:54 <mvollmer> as far as I can see 13:30:20 * fabiand checks that as well 13:30:23 <fabiand> could be that we need -v 13:30:37 <mvollmer> also, wouldn't multipath use multiple IPs anyway? 13:31:02 <mvollmer> so a singel discovery to a single IP will never show all the things that you want to login to to get multipath, no? 13:31:25 <fabiand> yes - I'm irritated by that - but it seems (and you can see that in the existnig cockpit ui already) that the disks (targets) can have different ips 13:31:58 <fabiand> you connect to a portal, and it seems that this portal can show all disks/targets with their different ips 13:32:29 <mvollmer> (however, if the have the same serial, storaged/cockpit should dtrt and expect devicemapper-multipath to set them up.) 13:32:46 <fabiand> $ sudo iscsiadm -m discovery -p 11.11.90.115 --type=sendtargets 13:32:46 <fabiand> 11.11.90.115:3260,1000 iqn.1992-08.com.netapp:sn.125053389 13:32:46 <fabiand> 11.11.90.116:3260,1001 iqn.1992-08.com.netapp:sn.125053389 13:32:53 <mvollmer> fabiand, aha, that makes sense indeed. 13:32:53 <petervo> mvollmer, sry i'm late 13:33:18 <mvollmer> and the iqn is the same! 13:33:21 <fabiand> mvollmer, indeed - if we see multiple disks with the same serial, then all of them need to be logged in and mpath should be started 13:33:23 <mvollmer> *click* 13:33:25 <fabiand> mvollmer, yep! 13:33:32 <mvollmer> serial == iqn! 13:33:36 * fabiand did not know if only the serial or something else was shown by iscsiadm 13:33:41 <mvollmer> not disk serial! 13:33:41 <fabiand> sort of, yes 13:33:57 <mvollmer> ok, we do that. 13:34:37 <mvollmer> so, no multiselect, but we need to cope with multiple IPs for the same iqn in the discovery results. 13:34:44 <andreasn> right 13:34:51 <fabiand> mvollmer, for completeness: 13:34:52 <fabiand> $ sudo iscsiadm -m discovery --type=sendtargets -p 11.11.8.222 13:34:52 <fabiand> 11.11.8.222:3260,1 iqn.2013-01.com:ha 13:34:52 <fabiand> 11.11.8.222:3260,1 iqn.2013-02.com:ha 13:34:52 <fabiand> 11.11.8.222:3260,1 iqn.2013-03.com:ha 13:34:52 <fabiand> 11.11.8.222:3260,1 iqn.2013-04.com:ha 13:35:02 <fabiand> that's how four individual (single pathed) targets/disks look like 13:35:22 <mvollmer> okay 13:36:11 <mvollmer> and normally, one iqn == one disk, right? 13:36:19 <fabiand> yes 13:36:22 <mvollmer> but sometimes, one iqn == multiple disks/luns. 13:36:38 <fabiand> mh ... 13:36:40 <mvollmer> or never? 13:36:43 <fabiand> hard to say yes here :) 13:37:01 <mvollmer> i think targetcli can be configured like that 13:37:01 <fabiand> let me find the right words 13:37:13 <fabiand> one disk always has one iqn 13:37:22 <mvollmer> it's just bl**dy scsi over ip, how can this be so complicated? 13:37:29 <jscotka> mvollmer, iqn should be unique disc identifier 13:37:37 <fabiand> but - that iqn can be exposed through multiple targets 13:37:45 <fabiand> and thus the multiple targets have the same iqn 13:38:17 <fabiand> but in some way, you can say: but sometimes, one iqn == multiple disks/luns 13:38:31 <fabiand> we can say it if we know what we mean :) 13:39:11 <mvollmer> one iqn == multiple block devices on the initiator 13:39:27 <mvollmer> but always, one iqn == one backing store. 13:39:40 <mvollmer> right? 13:39:46 <mvollmer> I try with targetcli. 13:40:25 <fabiand> I think it's called luns (or lun mapping) there 13:40:28 <fabiand> but yes, along this line, yes 13:41:37 <mvollmer> okay. 13:42:14 <mvollmer> fabiand, what do we do about iscsi-initiator-utils? 13:42:23 <mvollmer> https://bugzilla.redhat.com/show_bug.cgi?id=1262279 13:42:27 <fabiand> mvollmer, difficult imo 13:42:41 <fabiand> mvollmer, looks like the short term solution is to keep libiscsi in initator utils in fedora only 13:42:47 <fabiand> mvollmer, the long term is to upstream it ... 13:42:49 <fabiand> but that can take a while 13:43:04 <fabiand> u/s iscsi initiator utils wants api completeness before they merge it .. 13:43:27 <fabiand> that means, libiscsi should cover all functionality that is currently covered by the individual tools in iscsi-initiator-utils... 13:43:30 <fabiand> and that is some work .. 13:43:43 <fabiand> mvollmer, but in the end libiscsi should be there 13:43:57 * fabiand actually thought if it made more sense to pull libiscsi into storaged, but that does not make sense 13:44:11 <fabiand> mvollmer, and for the really short term: I hope that phatina's patch will soon be merge in fedora 13:44:40 <mvollmer> I hope we can do more than hope. 13:44:46 <fabiand> mvollmer, the issue is that neither me or phatina were able to merge the patch into the Fedora rawhide branch. That is why we need to leave it to the iscsi-nitiator utils maintainer 13:44:48 <mvollmer> :) 13:44:57 <fabiand> I believe that more can be done with more time 13:45:09 <fabiand> basically we just need to rbeuild the "Fedora tree" then we can apply the patch .. 13:46:24 <fabiand> mvollmer, one improvement would be to have a iscsi-initiator-utils tree with all the fdora patches somewhere - then new patches can be applied easily 13:46:25 <mvollmer> is there commitment to have the patch in Fedora 23? 13:46:28 <fabiand> this is just not the case right now 13:46:51 <fabiand> mvollmer, I don#t know about the timeline, but it sounds like there is nothing blocking that patch 13:46:53 <fabiand> just the lack of time 13:47:06 <mvollmer> okay 13:47:23 <mvollmer> let's see what happens then 13:48:40 <mvollmer> I have made a not about mpath: https://trello.com/c/PG1LJDX9/127-iscsi-initiator 13:48:57 <mvollmer> I'll get to that after the timesync stuff. 13:49:37 <mvollmer> okay, next? 13:49:40 <andreasn> sure 13:49:52 <mvollmer> #topic Open floor! 13:50:19 <mvollmer> sorry we took all this time with iSCSI 13:50:24 <stefw> Hopefully we can have a Vagrantfile going soon 13:50:27 <mvollmer> but that was good progress, thanks! 13:50:44 <stefw> in general, i'd like to do some work to make it easy for people to hack on pkg/ without doing an autogen.sh and configure 13:50:46 <fabiand> mvollmer, awesome iscsi work - really! 13:50:48 <stefw> that's just a heads up 13:51:04 <andreasn> great news re Vagrant 13:52:05 <stefw> the first step with vagrant is having people use it to test out pull requests 13:52:17 <stefw> hopefully we can have that working by the 0.79 release 13:57:04 <mvollmer> are we done? 13:57:12 <andreasn> I think so, yes 13:57:18 <mvollmer> alright 13:57:19 <stefw> yup 13:57:24 <mvollmer> thanks everyone! 13:57:28 <mvollmer> #endmeeting