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