Thursday, 2018-03-08

*** mylinux has quit IRC00:00
*** zerocoolback has quit IRC00:02
*** annabelleB has joined #kata-dev00:15
*** sameo has quit IRC00:18
*** oikiki has quit IRC00:26
*** oikiki has joined #kata-dev00:26
*** mylinux has joined #kata-dev00:31
*** mylinux has quit IRC00:36
*** sameo has joined #kata-dev00:38
*** sameo has quit IRC01:12
*** mylinux has joined #kata-dev01:16
*** eernst has quit IRC01:20
*** mylinux has quit IRC01:21
*** annabelleB has quit IRC01:55
*** mylinux has joined #kata-dev01:56
*** oikiki has quit IRC01:58
*** mylinux has quit IRC02:00
*** annabelleB has joined #kata-dev02:00
*** mcastelinn0 has joined #kata-dev02:23
*** mcastelinoo has quit IRC02:26
*** eocardon has left #kata-dev02:27
*** zerocoolback has joined #kata-dev02:32
*** mcastelinn0 has quit IRC02:32
*** zerocoolback has quit IRC02:32
*** zerocoolback has joined #kata-dev02:33
kata-dev-irc-bot<anne> Reminder for the LinuxCon/ContainerCon/CloudOpenCon happening in China in June. CFP is still open if anyone wants to submit! I've sent in a community onboarding session, maybe @xu would want to send something?! http://lfasiallc.com/events/lc3-2018/02:34
kata-dev-irc-bot<anne> closes march 11th IIRC02:35
kata-dev-irc-bot<xu> the hyper team has submit some topics, and @zhangwei555 and I together with a China based intel stuff have submitted a panel topic.02:36
kata-dev-irc-bot<xu> @anne I though it was closed on 4th originally02:37
kata-dev-irc-bot<anne> got extended for a few more days :slightly_smiling_face:02:37
kata-dev-irc-bot<xu> cool, a cfp extension is not really common in container world :,)02:39
kata-dev-irc-bot<anne> it's not! it's everyone's lucky day!02:40
*** annabelleB has quit IRC03:02
*** annabelleB has joined #kata-dev03:07
*** zerocoolback has quit IRC03:26
*** annabelleB has quit IRC03:47
*** annabelleB has joined #kata-dev03:50
*** eernst has joined #kata-dev03:58
*** eernst has quit IRC04:05
*** zerocoolback has joined #kata-dev04:20
*** mylinux has joined #kata-dev04:56
*** pabelanger has quit IRC04:58
*** mylinux has quit IRC05:01
*** sjas has joined #kata-dev05:57
*** sjas_ has quit IRC06:00
*** zerocoolback has quit IRC06:08
*** zerocoolback has joined #kata-dev06:08
*** zerocoolback has quit IRC06:10
*** zerocoolback has joined #kata-dev06:11
*** zerocoolback has quit IRC06:14
*** zerocoolback has joined #kata-dev06:15
*** zerocoolback has quit IRC06:19
*** dims has quit IRC06:24
*** zerocoolback has joined #kata-dev06:27
*** zerocoolback has quit IRC06:30
*** zerocoolback has joined #kata-dev06:30
*** dims has joined #kata-dev06:30
kata-dev-irc-bot<sebastien.boeuf> @laijs hey06:32
kata-dev-irc-bot<laijs> hey06:32
kata-dev-irc-bot<sebastien.boeuf> thanks for the comment here https://github.com/kata-containers/agent/pull/16306:33
kata-dev-irc-bot<sebastien.boeuf> what do you think about having a field `Rootfs bool` which would remove any confusion06:33
kata-dev-irc-bot<laijs> you are welcome06:33
*** annabelleB has quit IRC06:33
kata-dev-irc-bot<laijs> I don’t think so06:34
kata-dev-irc-bot<laijs> in host we do have storage drivers like aufs, devmapper, btrfs,…06:34
*** zerocoolback has quit IRC06:34
kata-dev-irc-bot<laijs> pb.Storage is designed to partially simulate it06:35
kata-dev-irc-bot<sebastien.boeuf> I get it but in that case the whole current implementation of agent is wrong06:36
kata-dev-irc-bot<sebastien.boeuf> I was more thinking about Storage like the description of what need to be mounted06:36
kata-dev-irc-bot<sebastien.boeuf> and Device about what actually represent a device06:36
kata-dev-irc-bot<sebastien.boeuf> and basically your block device is gonna be both06:37
kata-dev-irc-bot<laijs> I guest you want to split Device out from storage06:37
kata-dev-irc-bot<sebastien.boeuf> what do you mean ?06:37
kata-dev-irc-bot<laijs> pb.Storage handles all storage things likes host’s aufs, devmapper, btrfs. but it also need to reslove the device which is duplicated with pb.Device06:39
kata-dev-irc-bot<sebastien.boeuf> yes exactly, that's why I need both in this case to solve such a case06:40
kata-dev-irc-bot<sebastien.boeuf> I thought the split was clear when I have introduced `Device`06:40
kata-dev-irc-bot<sebastien.boeuf> cause if I follow your logic, then everything should be described in Storage06:41
kata-dev-irc-bot<sebastien.boeuf> but I was really thinking that Storage was responsible for everything related to the filesystem, meaning a mount basically, while device was responsible for all the details related to the device itself06:42
kata-dev-irc-bot<laijs> yes06:44
kata-dev-irc-bot<sebastien.boeuf> for a devicemapper rootfs, we have a hotplugged block device which will show up inside the VM, this needs to be taken care of by `Device`. Once this device has been properly detected inside, we rely on Storage to know where this device should be mounted and with which filesystem06:44
*** annabelleB has joined #kata-dev06:46
kata-dev-irc-bot<laijs> actually, device can be bind mounted from vm_path into container_path via pb.Storage instead of `mknod`, It is allowed by oci-spec, shall we try this.06:48
kata-dev-irc-bot<laijs> so that we can focus on pb.Storage06:50
kata-dev-irc-bot<sebastien.boeuf> hmm, I get your point. So we would use `Device` for any device passed through the VM, while we would use `Storage` for rootfs and any volume06:52
kata-dev-irc-bot<sebastien.boeuf> And both `Device` and `Storage` would actually call into the same functions inside the agent to wait for a block device for instance06:54
kata-dev-irc-bot<laijs> we would use `Storage` for rootfs and any volume, and we can also use Storage for any device passed through the VM(use bind mount), so we can implement the driver in one place.06:54
kata-dev-irc-bot<laijs> At least, I insist that we would use `Storage` for rootfs and any volume.06:55
kata-dev-irc-bot<sebastien.boeuf> This makes sense, but this goes further than my SCSI PR then06:57
kata-dev-irc-bot<sebastien.boeuf> we need to rework the way it works right now for blk06:57
kata-dev-irc-bot<sebastien.boeuf> But even if we do that, it'd be easier to have a flag to identify we're dealing with a rootfs. I am saying this because for rootfs, there will be no corresponding entry into `oci.Device` or `oci.Mount`07:00
kata-dev-irc-bot<sebastien.boeuf> @laijs ok here is the proposal. I can rework the current block device handling so that we actually use Storage if it's a rootfs or a volume passed as a device. `Storage` will only be related to `oci.Mount` and `Device` to `oci.Device`. This way we need one function `AddStorages()` and one `AddDevices()`, both called from `CreateContainer()` in `grpc.go`. They can both be called interchangeably, because they are not tied by07:11
kata-dev-irc-botdefining the same things. And I really want to add a `RootFs bool` field to the `Storage` structure so that we can cleanly identify it.07:11
kata-dev-irc-bot<laijs> > there will be no corresponding entry into `oci.Device` or `oci.Mount` but there will be ocispec.Root.Path which can also help with it to use the rootfs07:13
kata-dev-irc-bot<laijs> use pb.Storage to mount the rootfs on some place and use ocispec.Root.Path to point to it.07:14
*** zerocoolback has joined #kata-dev07:17
kata-dev-irc-bot<sebastien.boeuf> but you need to make the diff with a volume07:20
kata-dev-irc-bot<sebastien.boeuf> @laijs I gotta go, but please explain on the PR https://github.com/kata-containers/agent/pull/163 how you see things to work exactly, and I'll try to implement it tomorrow07:21
*** jodh has joined #kata-dev07:37
*** jodh has quit IRC07:37
*** jodh has joined #kata-dev07:37
*** zerocoolback has quit IRC07:47
*** annabelleB has quit IRC08:14
*** annabelleB has joined #kata-dev08:43
*** annabelleB has quit IRC08:56
*** gwhaley has joined #kata-dev09:13
*** mylinux has joined #kata-dev09:18
*** zerocoolback has joined #kata-dev09:38
*** pabelanger has joined #kata-dev09:41
*** cdent has joined #kata-dev09:47
*** mylinux has quit IRC09:50
*** cdent has quit IRC10:03
*** zerocoolback has quit IRC10:05
*** mylinux has joined #kata-dev10:21
*** mylinux has quit IRC10:27
*** mylinux has joined #kata-dev10:53
*** mylinux has quit IRC10:58
*** mylinux has joined #kata-dev11:24
*** cdent has joined #kata-dev11:27
*** mylinux has quit IRC11:30
*** mylinux has joined #kata-dev11:58
*** gwhaley has quit IRC12:00
*** mylinux has quit IRC12:03
*** zerocoolback has joined #kata-dev12:04
*** pabelanger_ has joined #kata-dev12:27
*** pabelanger has quit IRC12:29
*** zerocoolback has quit IRC12:49
*** annabelleB has joined #kata-dev13:09
*** pabelanger_ is now known as pabelanger13:10
*** gwhaley has joined #kata-dev13:22
*** zerocoolback has joined #kata-dev13:24
*** mylinux has joined #kata-dev13:24
*** mylinux has quit IRC13:29
stefanhaWhat is the advantage of USE_DOCKER=true rootfs.sh?  It's not obvious to me why I would want or not want to use Docker to build the rootfs.13:30
*** fuentess has joined #kata-dev13:32
*** fuentess has quit IRC13:37
*** devimc has joined #kata-dev13:38
kata-dev-irc-bot<ydjainopensource> U may use docker to avoid installing dependencies directly on your computer13:42
kata-dev-irc-bot<ydjainopensource> With use_docker a container with dependencies required to build a rootfs is created which in turn generates the rootfs13:43
gwhaleyexactly - and the script only supports some of the dependancies for some distros I think - so we use USE_DOCKER on a fedora system for instance13:46
*** annabelleB has quit IRC14:03
stefanhaydjainopensource & gwhaley: Thanks!14:14
*** rcw has joined #kata-dev14:15
*** eocardon has joined #kata-dev14:35
*** eernst has joined #kata-dev15:21
*** mylinux has joined #kata-dev15:24
*** mylinux has quit IRC15:28
*** mylinux has joined #kata-dev15:49
*** zerocoolback has quit IRC16:18
*** eernst has quit IRC16:19
*** mylinux has quit IRC16:21
*** zerocoolback has joined #kata-dev16:24
*** mylinux has joined #kata-dev16:28
*** zerocoolback has quit IRC16:29
*** justJanne is now known as justjanneTest16:31
*** justjanneTest is now known as justJanne16:31
*** mylinux has quit IRC16:33
*** mylinux has joined #kata-dev16:34
*** mylinux has quit IRC16:38
*** devimc has quit IRC16:52
*** eernst has joined #kata-dev16:52
*** mcastelino has joined #kata-dev17:00
*** mcastelino has quit IRC17:00
*** mcastelino has joined #kata-dev17:00
*** gabyc_ has joined #kata-dev17:16
*** oikiki has joined #kata-dev17:42
*** jodh has quit IRC18:04
*** devimc has joined #kata-dev18:07
*** gabyc_1 has joined #kata-dev18:08
*** gabyc_ has quit IRC18:08
*** manjeets has joined #kata-dev18:20
*** gwhaley has quit IRC18:46
*** cdent has quit IRC18:56
*** oikiki has quit IRC19:41
*** eernst has quit IRC20:10
*** eernst has joined #kata-dev20:10
*** eernst has quit IRC20:54
*** eernst has joined #kata-dev20:54
*** rcwoolley_ has joined #kata-dev21:07
*** rcw has quit IRC21:10
*** rwoolley__ has joined #kata-dev21:14
*** rwoolley__ has quit IRC21:15
*** rcwoolley_ has quit IRC21:16
*** oikiki has joined #kata-dev21:29
*** oikiki has quit IRC21:31
*** oikiki has joined #kata-dev21:32
*** oikiki has quit IRC21:39
*** oikiki has joined #kata-dev22:05
*** oikiki has quit IRC22:13
*** oikiki has joined #kata-dev22:13
*** eernst has quit IRC22:21
*** eernst has joined #kata-dev22:22
*** devimc has quit IRC22:27
*** annabelleB has joined #kata-dev22:32
*** annabelleB has quit IRC22:33
*** annabelleB has joined #kata-dev22:34
*** gabyc_1 has quit IRC22:36
*** oikiki has quit IRC23:11
*** oikiki has joined #kata-dev23:19
*** annabelleB has quit IRC23:24

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!