Gris Ge
2014-03-19 23:01:38 UTC
Time line is GMT+8
[2014-03-20 05:05] <fge> tasleson: Greating.
[2014-03-20 05:05] <tasleson> fge: Hello
[2014-03-20 05:06] <tasleson> fge: Topic(s)?
[2014-03-20 05:06] <fge> I only have API clean up thing to discuss.
[2014-03-20 05:06] <tasleson> C or Python or both?
[2014-03-20 05:06] <fge> Both.
[2014-03-20 05:07] <tasleson> Go a head :-)
[2014-03-20 05:07] <fge> In C API, we use LsmNounVerb, in Python API, we use noun_verb.
[2014-03-20 05:08] <fge> can we unifiy that to lsm_noun_verb?
[2014-03-20 05:08] <fge> that was suggested by libabc and PEP8.
[2014-03-20 05:08] <fge> or LSM_noun_verb which was used by libmicrohttpd
[2014-03-20 05:09] <tasleson> So your main issue is with the camelCase?
[2014-03-20 05:10] <fge> main issue was inconsistancy of C API and Python API.
[2014-03-20 05:10] <fge> lsmVolumeCreate() vs volume_create()
[2014-03-20 05:11] <tasleson> We don't have namespaces in C so they will need to be different
[2014-03-20 05:11] <tasleson> I was following libVirt: http://libvirt.org/html/libvirt-libvirt.html for C API
[2014-03-20 05:13] <fge> did they provide different name in their python API?
[2014-03-20 05:13] <tasleson> Good question
[2014-03-20 05:13] <fge> http://libvirt.org/python.html
[2014-03-20 05:14] <fge> Actually, they provide identical name.
[2014-03-20 05:14] <tasleson> Yep :-)
[2014-03-20 05:14] <fge> not exactly identical.
[2014-03-20 05:15] <tasleson> Yeah, but closer
[2014-03-20 05:15] --> grover (~***@198.145.19.7) has joined this channel.
[2014-03-20 05:15] <fge> So, I suggest, lsm_volume_create() -> lsm::volume_create()
[2014-03-20 05:17] <fge> for camelCase, it looks like a C++ binding to me when Linux kernel suggest xxx_yyy_zzz lower case format.
[2014-03-20 05:17] <tasleson> Well I guess I was trying to follow pep8 for python which is method names are lowercase separated by '_' s
[2014-03-20 05:17] <fge> actually, libabc and linux kernel code style suggest the same for C API.
[2014-03-20 05:18] <tasleson> So just remove camel case from C and replace with '_'s?
[2014-03-20 05:18] <fge> yes.
[2014-03-20 05:19] <fge> next topic?
[2014-03-20 05:19] <tasleson> grover: Your thoughts on this?
[2014-03-20 05:20] <fge> in case he missed the whole story: we are talking about unifiying the method name used in C API and Python API.
[2014-03-20 05:21] <tasleson> I sent him a pastebin with history
[2014-03-20 05:22] <grover> hmm
[2014-03-20 05:22] <tasleson> I guess I'm OK with changing the C API to remove camel case and replacing with '_'s
[2014-03-20 05:22] <tasleson> Honestly, I'm OK either way :-)
[2014-03-20 05:22] <grover> fine by me
[2014-03-20 05:23] <tasleson> OK, change approved. I will submit a patch soon that makes this change
[2014-03-20 05:23] <tasleson> Next...
[2014-03-20 05:24] <tasleson> Gris you had another topic?
[2014-03-20 05:24] <fge> tasleson: 1 sec
[2014-03-20 05:24] <tasleson> np
[2014-03-20 05:24] <fge> let me check C API detail for example
[2014-03-20 05:25] <fge> do we have to create function like lsmVolumeIdGet() in python API?
[2014-03-20 05:25] <fge> or we still want them to use pool.id
[2014-03-20 05:25] <tasleson> No, I was going to use the python property
[2014-03-20 05:26] <tasleson> The C API uses opaque data types, so it needs get/set functions
[2014-03-20 05:26] <tasleson> Python with the properties, we can change the implementation without changing the API
[2014-03-20 05:27] <fge> libvirt using virDomainGetInfo() to get all properties at one call.
[2014-03-20 05:27] <fge> which they save the mount of function count.
[2014-03-20 05:28] <tasleson> Well they return a virDomainGetInfoPtr, how do you access data from that?
[2014-03-20 05:29] <tasleson> Ok, so they exposed a structure.
[2014-03-20 05:29] <fge> Yes.
[2014-03-20 05:29] <tasleson> Once you do that it can't change, so the next time you want to add a field what to you do?
[2014-03-20 05:30] <fge> optional data.
[2014-03-20 05:30] <tasleson> libabc says NO to using structs for this reason
[2014-03-20 05:30] <fge> checking
[2014-03-20 05:31] <tasleson> Look at https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/plain/README section "Do not expose any complex structures in your API"
[2014-03-20 05:33] <fge> ok. change request dismissed.
[2014-03-20 05:33] <tasleson> I know it's a pain having so many functions, but it does give a lot of benefits
[2014-03-20 05:33] <tasleson> Next
[2014-03-20 05:34] <fge> In Python API, System.STATUS_DEGRADED string is 'Degraded', Pool.STATUS_DEGRADED string is 'DEGRADED'.
[2014-03-20 05:35] <fge> which one would you prefer?
[2014-03-20 05:35] <tasleson> What is the string used for again :-)
[2014-03-20 05:35] <tasleson> Human consumption?
[2014-03-20 05:36] <fge> yes. cmdline.py use to convert System.STATUS_DEGRADED to human readable string.
[2014-03-20 05:36] <tasleson> Probably go with 'Degraded' then
[2014-03-20 05:37] <fge> As you change xxx_type_to_string() as private, can we move related functions to cmdline.py?
[2014-03-20 05:40] <tasleson> Well the implementation of those functions uses data on the class which is private too...
[2014-03-20 05:40] <fge> I am expecting cmdline.py as a example of python API user case, but we are using private method: obj._value_of_key()
[2014-03-20 05:41] <tasleson> Oh, I see, let me think about that
[2014-03-20 05:46] <fge> let's postpone this topic to next meeting. OK?
[2014-03-20 05:46] <tasleson> Sure
[2014-03-20 05:46] <fge> where we could get enought time to think it through.
[2014-03-20 05:47] <tasleson> I didn't think about using cmdline.py as example usage
[2014-03-20 05:47] <fge> but keeping _value_of_key() in client.py only for cmdline.py?
[2014-03-20 05:49] <tasleson> Yeah, let me look at what we can do. I'll post a patch proposal
[2014-03-20 05:50] <tasleson> In general I don't want cmdline.py as public as I want to be able to change it
[2014-03-20 05:51] <fge> I think as long as we don't change the output format of cmdline.py.
[2014-03-20 05:51] <fge> and don't change command line options.
[2014-03-20 05:51] <fge> it will be treat as stable since cmdline does not contribute to API functions.
[2014-03-20 05:52] <tasleson> Well I was thinking more of API user wanting to call the cmdline object
[2014-03-20 05:53] <fge> how about we postpone this topic to next meeting.
[2014-03-20 05:53] <tasleson> Sure :-)
[2014-03-20 05:53] <fge> I need to think the whole thing through.
[2014-03-20 05:53] <fge> And we can work on patch proposal after that.
[2014-03-20 05:54] <tasleson> My main concern is whatever we have in the library that a user can access via lsm.* and it isn't prefixed with an '_' then we need to maintain it and not change it
[2014-03-20 05:54] <tasleson> I like being able to make improvements and changes :-)
[2014-03-20 05:55] <fge> then CmdLine should be removed from lsm namespace.
[2014-03-20 05:55] <tasleson> I believe it already is with my latest patch
[2014-03-20 05:56] <fge> Great.
[2014-03-20 05:56] <tasleson> Not in __init__.py and renamed to _cmdline.py
[2014-03-20 05:56] <fge> so it's not in lsm namespace but using lsm private methods.
[2014-03-20 05:57] <tasleson> Yes, library code is free to call other library code that is private
[2014-03-20 05:57] <grover> is it feasible to have lsmcli just use public apis?
[2014-03-20 05:58] <fge> yes.
[2014-03-20 06:03] <fge> before teuf back to sleep, we can move on to next topic about IRC reschedule?
[2014-03-20 06:03] <tasleson> Sure
[2014-03-20 06:04] <fge> it's pretty hard for me to wake up at 5:00 AM. (I don't want to join 4:00 AM SNIA meeting any more).
[2014-03-20 06:04] <tasleson> Understood
[2014-03-20 06:04] <tasleson> I'm not a morning person either
[2014-03-20 06:05] <fge> Let's say GMT +8 11:00 PM.
[2014-03-20 06:05] <fge> what time was it in your timezone summer and winter.
[2014-03-20 06:05] <fge> for teuf, GMT+2, it's 5:00 PM.
[2014-03-20 06:06] <tasleson> I'm GMT - 5
[2014-03-20 06:06] <fge> 10:00 AM
[2014-03-20 06:07] <fge> and 9:00 AM for day night saving?
[2014-03-20 06:07] <tasleson> Sound correct
[2014-03-20 06:08] <fge> is that time apperate for you?
[2014-03-20 06:08] <fge> and how about you, grover?
[2014-03-20 06:09] <tasleson> That would be 8am for Grover
[2014-03-20 06:09] <fge> woo.
[2014-03-20 06:09] <grover> yay
[2014-03-20 06:09] <tasleson> Andy that be too early for you?
[2014-03-20 06:10] <fge> but if I put one hour behide, it's 11:00 AM - 12:00 AM for tony.
[2014-03-20 06:10] <fge> that seem lunch time.
[2014-03-20 06:10] <tasleson> I'm OK with meetings over normal lunch time
[2014-03-20 06:10] <tasleson> Kind of late for you though Gris
[2014-03-20 06:10] <grover> I'm ok with 8am
[2014-03-20 06:11] <fge> Thanks.
[2014-03-20 06:11] <fge> ok. The calendar time will be based on GMT+8 (we don't have day night saving) 11:00 PM.
[2014-03-20 06:11] <fge> I will send out a calendar change to mailist.
[2014-03-20 06:12] <tasleson> Thanks
[2014-03-20 06:13] <fge> next topic is discussing the email reply from me about python API function naming scheme.
[2014-03-20 06:13] <tasleson> Ok
[2014-03-20 06:14] <fge> any feedback on that changes?
[2014-03-20 06:16] <fge> http://pastebin.com/D3X7cFhv in case someone missed the mail.
[2014-03-20 06:16] <tasleson> I have quite a bit actually, I was in the middle of an email that I didn't finish. Want me to go over now or wait until I send out email?
[2014-03-20 06:17] <fge> we can review that list in next meeting.
[2014-03-20 06:17] <tasleson> OK
[2014-03-20 06:17] <fge> the your C API changes has to wait.
[2014-03-20 06:18] <tasleson> Sorry, not understanding that last statement?
[2014-03-20 06:18] <fge> if we are changing the name of python API functions, C API functions will be changed also.
[2014-03-20 06:18] <tasleson> Yes, that makes sense
[2014-03-20 06:19] <fge> just one thing I would like to talk about in that change list today
[2014-03-20 06:19] <tasleson> Sure
[2014-03-20 06:20] <fge> remove initiator class by merge into access group.
[2014-03-20 06:20] <fge> for any plugin which does not support group masking, we treat their every initiator as a group.
[2014-03-20 06:20] <tasleson> Targetd doesn't support access groups, so grover would need to rework targetd daemon.
[2014-03-20 06:21] <fge> you mean targetd.py?
[2014-03-20 06:21] <grover> is targetd the only plugin that doesn't support access groups?
[2014-03-20 06:22] <tasleson> Let me see if nstor does
[2014-03-20 06:22] <fge> nstor: yes.
[2014-03-20 06:22] <grover> there would need to be some work done but it's possible now
[2014-03-20 06:23] <tasleson> Concur, nstor has access groups
[2014-03-20 06:23] <grover> sure, I can add this to targetd
[2014-03-20 06:23] <fge> I will do the merging work in python API.
[2014-03-20 06:23] <tasleson> fge: targetd i.e. https://github.com/agrover/targetd
[2014-03-20 06:24] <fge> tasleson: thanks. Havn't got a chance to try it. Will do.
[2014-03-20 06:24] <tasleson> The targetd plug-in would need to be refactored
[2014-03-20 06:24] <tasleson> fge: Why do you want to remove initiator methods?
[2014-03-20 06:25] <tasleson> To simplify?
[2014-03-20 06:25] <fge> yes.
[2014-03-20 06:25] <fge> and will confuse user when some plugin support both.
[2014-03-20 06:25] <tasleson> I don't think any actually do.
[2014-03-20 06:26] <tasleson> Interestingly I initially had only initiator, then moved to only access group, then brought the initiator stuff back for targetd :-)
[2014-03-20 06:27] <grover> what's the timeframe for this change?
[2014-03-20 06:27] <tasleson> Well sooner would be better :-)
[2014-03-20 06:27] <fge> :)
[2014-03-20 06:27] <grover> hah ok
[2014-03-20 06:28] <grover> I'll try to get to it soon
[2014-03-20 06:28] <tasleson> My concern is if there is any arrays that don't support access groups outside of targetd and what we would do then.
[2014-03-20 06:28] <tasleson> Gris mentioned turn every initiator into a group on the fly
[2014-03-20 06:28] <fge> Treat every initiator as a group.
[2014-03-20 06:29] <fge> In SAN world, I see no array support initator mask only.
[2014-03-20 06:29] <grover> the plugin would throw an error if a 2nd initiator was added to a group?
[2014-03-20 06:29] <tasleson> fge: Could you supply a patch for targetd plugin that does what you suggest?
[2014-03-20 06:30] <fge> tasleson: will do.
[2014-03-20 06:30] <tasleson> If it works, then targetd doesn't have to change right away
[2014-03-20 06:30] <fge> grover: ErrorNumber.NO_SUPPORT will do.
[2014-03-20 06:31] <tasleson> OK anything else?
[2014-03-20 06:31] <fge> None.
[2014-03-20 06:31] <fge> I am done.
[2014-03-20 06:32] <tasleson> OK, I will get a response out to your email ASAP for the python API changes.
[2014-03-20 06:32] <grover> so for now we're just saying instead of a flag that a plugin doesn't support groups, there won't be a flag but the plugin will return no_support, right?
[2014-03-20 06:32] <grover> and then later targetd will gain support and no longer return that error
[2014-03-20 06:32] <fge> grover: I am about to change LSM plugin to treat every initiator as a group.
[2014-03-20 06:33] <fge> grover: and raise ErrorNumber.NO_SUPPORT if adding 2nd initator to that group.
[2014-03-20 06:33] <tasleson> Well, if we go forward with gris's approach, then every array must support access groups
[2014-03-20 06:33] <fge> grover: that might save some time for you to support access group.
[2014-03-20 06:33] <tasleson> Just in targetd case simplified representation
[2014-03-20 06:34] <fge> that's better.
[2014-03-20 06:34] <grover> ok
[2014-03-20 06:35] <fge> so the aggreement of this is: wait grover to change targetd to expose access group?
[2014-03-20 06:36] <tasleson> Yes, I would like fge to supply patch demonstrating access groups for array that doesn't support them.
[2014-03-20 06:36] <tasleson> That way we will be covered if it shows up for other array
[2014-03-20 06:36] <fge> noted.
[2014-03-20 06:36] <tasleson> We can then add true access group support to targetd if we want later
[2014-03-20 06:37] <fge> so. 1. I provide patches change lsm targetd.py plugin to support access group in workaround way.
[2014-03-20 06:38] <fge> 2. Once grover finished true access group support, I update targetd.py for that.
[2014-03-20 06:39] <grover> I'm happy to update targetd.py in step 2 as well as the array code
[2014-03-20 06:39] <fge> ok. I take step 1 to show possiblity of supporting initiator-only array.
[2014-03-20 06:40] <fge> Are we done?
[2014-03-20 06:40] <tasleson> Yeah, I think so. Thanks everyone!
[2014-03-20 06:40] <fge> Thank you and grover. Have a good night/day/
[2014-03-20 05:05] <fge> tasleson: Greating.
[2014-03-20 05:05] <tasleson> fge: Hello
[2014-03-20 05:06] <tasleson> fge: Topic(s)?
[2014-03-20 05:06] <fge> I only have API clean up thing to discuss.
[2014-03-20 05:06] <tasleson> C or Python or both?
[2014-03-20 05:06] <fge> Both.
[2014-03-20 05:07] <tasleson> Go a head :-)
[2014-03-20 05:07] <fge> In C API, we use LsmNounVerb, in Python API, we use noun_verb.
[2014-03-20 05:08] <fge> can we unifiy that to lsm_noun_verb?
[2014-03-20 05:08] <fge> that was suggested by libabc and PEP8.
[2014-03-20 05:08] <fge> or LSM_noun_verb which was used by libmicrohttpd
[2014-03-20 05:09] <tasleson> So your main issue is with the camelCase?
[2014-03-20 05:10] <fge> main issue was inconsistancy of C API and Python API.
[2014-03-20 05:10] <fge> lsmVolumeCreate() vs volume_create()
[2014-03-20 05:11] <tasleson> We don't have namespaces in C so they will need to be different
[2014-03-20 05:11] <tasleson> I was following libVirt: http://libvirt.org/html/libvirt-libvirt.html for C API
[2014-03-20 05:13] <fge> did they provide different name in their python API?
[2014-03-20 05:13] <tasleson> Good question
[2014-03-20 05:13] <fge> http://libvirt.org/python.html
[2014-03-20 05:14] <fge> Actually, they provide identical name.
[2014-03-20 05:14] <tasleson> Yep :-)
[2014-03-20 05:14] <fge> not exactly identical.
[2014-03-20 05:15] <tasleson> Yeah, but closer
[2014-03-20 05:15] --> grover (~***@198.145.19.7) has joined this channel.
[2014-03-20 05:15] <fge> So, I suggest, lsm_volume_create() -> lsm::volume_create()
[2014-03-20 05:17] <fge> for camelCase, it looks like a C++ binding to me when Linux kernel suggest xxx_yyy_zzz lower case format.
[2014-03-20 05:17] <tasleson> Well I guess I was trying to follow pep8 for python which is method names are lowercase separated by '_' s
[2014-03-20 05:17] <fge> actually, libabc and linux kernel code style suggest the same for C API.
[2014-03-20 05:18] <tasleson> So just remove camel case from C and replace with '_'s?
[2014-03-20 05:18] <fge> yes.
[2014-03-20 05:19] <fge> next topic?
[2014-03-20 05:19] <tasleson> grover: Your thoughts on this?
[2014-03-20 05:20] <fge> in case he missed the whole story: we are talking about unifiying the method name used in C API and Python API.
[2014-03-20 05:21] <tasleson> I sent him a pastebin with history
[2014-03-20 05:22] <grover> hmm
[2014-03-20 05:22] <tasleson> I guess I'm OK with changing the C API to remove camel case and replacing with '_'s
[2014-03-20 05:22] <tasleson> Honestly, I'm OK either way :-)
[2014-03-20 05:22] <grover> fine by me
[2014-03-20 05:23] <tasleson> OK, change approved. I will submit a patch soon that makes this change
[2014-03-20 05:23] <tasleson> Next...
[2014-03-20 05:24] <tasleson> Gris you had another topic?
[2014-03-20 05:24] <fge> tasleson: 1 sec
[2014-03-20 05:24] <tasleson> np
[2014-03-20 05:24] <fge> let me check C API detail for example
[2014-03-20 05:25] <fge> do we have to create function like lsmVolumeIdGet() in python API?
[2014-03-20 05:25] <fge> or we still want them to use pool.id
[2014-03-20 05:25] <tasleson> No, I was going to use the python property
[2014-03-20 05:26] <tasleson> The C API uses opaque data types, so it needs get/set functions
[2014-03-20 05:26] <tasleson> Python with the properties, we can change the implementation without changing the API
[2014-03-20 05:27] <fge> libvirt using virDomainGetInfo() to get all properties at one call.
[2014-03-20 05:27] <fge> which they save the mount of function count.
[2014-03-20 05:28] <tasleson> Well they return a virDomainGetInfoPtr, how do you access data from that?
[2014-03-20 05:29] <tasleson> Ok, so they exposed a structure.
[2014-03-20 05:29] <fge> Yes.
[2014-03-20 05:29] <tasleson> Once you do that it can't change, so the next time you want to add a field what to you do?
[2014-03-20 05:30] <fge> optional data.
[2014-03-20 05:30] <tasleson> libabc says NO to using structs for this reason
[2014-03-20 05:30] <fge> checking
[2014-03-20 05:31] <tasleson> Look at https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/plain/README section "Do not expose any complex structures in your API"
[2014-03-20 05:33] <fge> ok. change request dismissed.
[2014-03-20 05:33] <tasleson> I know it's a pain having so many functions, but it does give a lot of benefits
[2014-03-20 05:33] <tasleson> Next
[2014-03-20 05:34] <fge> In Python API, System.STATUS_DEGRADED string is 'Degraded', Pool.STATUS_DEGRADED string is 'DEGRADED'.
[2014-03-20 05:35] <fge> which one would you prefer?
[2014-03-20 05:35] <tasleson> What is the string used for again :-)
[2014-03-20 05:35] <tasleson> Human consumption?
[2014-03-20 05:36] <fge> yes. cmdline.py use to convert System.STATUS_DEGRADED to human readable string.
[2014-03-20 05:36] <tasleson> Probably go with 'Degraded' then
[2014-03-20 05:37] <fge> As you change xxx_type_to_string() as private, can we move related functions to cmdline.py?
[2014-03-20 05:40] <tasleson> Well the implementation of those functions uses data on the class which is private too...
[2014-03-20 05:40] <fge> I am expecting cmdline.py as a example of python API user case, but we are using private method: obj._value_of_key()
[2014-03-20 05:41] <tasleson> Oh, I see, let me think about that
[2014-03-20 05:46] <fge> let's postpone this topic to next meeting. OK?
[2014-03-20 05:46] <tasleson> Sure
[2014-03-20 05:46] <fge> where we could get enought time to think it through.
[2014-03-20 05:47] <tasleson> I didn't think about using cmdline.py as example usage
[2014-03-20 05:47] <fge> but keeping _value_of_key() in client.py only for cmdline.py?
[2014-03-20 05:49] <tasleson> Yeah, let me look at what we can do. I'll post a patch proposal
[2014-03-20 05:50] <tasleson> In general I don't want cmdline.py as public as I want to be able to change it
[2014-03-20 05:51] <fge> I think as long as we don't change the output format of cmdline.py.
[2014-03-20 05:51] <fge> and don't change command line options.
[2014-03-20 05:51] <fge> it will be treat as stable since cmdline does not contribute to API functions.
[2014-03-20 05:52] <tasleson> Well I was thinking more of API user wanting to call the cmdline object
[2014-03-20 05:53] <fge> how about we postpone this topic to next meeting.
[2014-03-20 05:53] <tasleson> Sure :-)
[2014-03-20 05:53] <fge> I need to think the whole thing through.
[2014-03-20 05:53] <fge> And we can work on patch proposal after that.
[2014-03-20 05:54] <tasleson> My main concern is whatever we have in the library that a user can access via lsm.* and it isn't prefixed with an '_' then we need to maintain it and not change it
[2014-03-20 05:54] <tasleson> I like being able to make improvements and changes :-)
[2014-03-20 05:55] <fge> then CmdLine should be removed from lsm namespace.
[2014-03-20 05:55] <tasleson> I believe it already is with my latest patch
[2014-03-20 05:56] <fge> Great.
[2014-03-20 05:56] <tasleson> Not in __init__.py and renamed to _cmdline.py
[2014-03-20 05:56] <fge> so it's not in lsm namespace but using lsm private methods.
[2014-03-20 05:57] <tasleson> Yes, library code is free to call other library code that is private
[2014-03-20 05:57] <grover> is it feasible to have lsmcli just use public apis?
[2014-03-20 05:58] <fge> yes.
[2014-03-20 06:03] <fge> before teuf back to sleep, we can move on to next topic about IRC reschedule?
[2014-03-20 06:03] <tasleson> Sure
[2014-03-20 06:04] <fge> it's pretty hard for me to wake up at 5:00 AM. (I don't want to join 4:00 AM SNIA meeting any more).
[2014-03-20 06:04] <tasleson> Understood
[2014-03-20 06:04] <tasleson> I'm not a morning person either
[2014-03-20 06:05] <fge> Let's say GMT +8 11:00 PM.
[2014-03-20 06:05] <fge> what time was it in your timezone summer and winter.
[2014-03-20 06:05] <fge> for teuf, GMT+2, it's 5:00 PM.
[2014-03-20 06:06] <tasleson> I'm GMT - 5
[2014-03-20 06:06] <fge> 10:00 AM
[2014-03-20 06:07] <fge> and 9:00 AM for day night saving?
[2014-03-20 06:07] <tasleson> Sound correct
[2014-03-20 06:08] <fge> is that time apperate for you?
[2014-03-20 06:08] <fge> and how about you, grover?
[2014-03-20 06:09] <tasleson> That would be 8am for Grover
[2014-03-20 06:09] <fge> woo.
[2014-03-20 06:09] <grover> yay
[2014-03-20 06:09] <tasleson> Andy that be too early for you?
[2014-03-20 06:10] <fge> but if I put one hour behide, it's 11:00 AM - 12:00 AM for tony.
[2014-03-20 06:10] <fge> that seem lunch time.
[2014-03-20 06:10] <tasleson> I'm OK with meetings over normal lunch time
[2014-03-20 06:10] <tasleson> Kind of late for you though Gris
[2014-03-20 06:10] <grover> I'm ok with 8am
[2014-03-20 06:11] <fge> Thanks.
[2014-03-20 06:11] <fge> ok. The calendar time will be based on GMT+8 (we don't have day night saving) 11:00 PM.
[2014-03-20 06:11] <fge> I will send out a calendar change to mailist.
[2014-03-20 06:12] <tasleson> Thanks
[2014-03-20 06:13] <fge> next topic is discussing the email reply from me about python API function naming scheme.
[2014-03-20 06:13] <tasleson> Ok
[2014-03-20 06:14] <fge> any feedback on that changes?
[2014-03-20 06:16] <fge> http://pastebin.com/D3X7cFhv in case someone missed the mail.
[2014-03-20 06:16] <tasleson> I have quite a bit actually, I was in the middle of an email that I didn't finish. Want me to go over now or wait until I send out email?
[2014-03-20 06:17] <fge> we can review that list in next meeting.
[2014-03-20 06:17] <tasleson> OK
[2014-03-20 06:17] <fge> the your C API changes has to wait.
[2014-03-20 06:18] <tasleson> Sorry, not understanding that last statement?
[2014-03-20 06:18] <fge> if we are changing the name of python API functions, C API functions will be changed also.
[2014-03-20 06:18] <tasleson> Yes, that makes sense
[2014-03-20 06:19] <fge> just one thing I would like to talk about in that change list today
[2014-03-20 06:19] <tasleson> Sure
[2014-03-20 06:20] <fge> remove initiator class by merge into access group.
[2014-03-20 06:20] <fge> for any plugin which does not support group masking, we treat their every initiator as a group.
[2014-03-20 06:20] <tasleson> Targetd doesn't support access groups, so grover would need to rework targetd daemon.
[2014-03-20 06:21] <fge> you mean targetd.py?
[2014-03-20 06:21] <grover> is targetd the only plugin that doesn't support access groups?
[2014-03-20 06:22] <tasleson> Let me see if nstor does
[2014-03-20 06:22] <fge> nstor: yes.
[2014-03-20 06:22] <grover> there would need to be some work done but it's possible now
[2014-03-20 06:23] <tasleson> Concur, nstor has access groups
[2014-03-20 06:23] <grover> sure, I can add this to targetd
[2014-03-20 06:23] <fge> I will do the merging work in python API.
[2014-03-20 06:23] <tasleson> fge: targetd i.e. https://github.com/agrover/targetd
[2014-03-20 06:24] <fge> tasleson: thanks. Havn't got a chance to try it. Will do.
[2014-03-20 06:24] <tasleson> The targetd plug-in would need to be refactored
[2014-03-20 06:24] <tasleson> fge: Why do you want to remove initiator methods?
[2014-03-20 06:25] <tasleson> To simplify?
[2014-03-20 06:25] <fge> yes.
[2014-03-20 06:25] <fge> and will confuse user when some plugin support both.
[2014-03-20 06:25] <tasleson> I don't think any actually do.
[2014-03-20 06:26] <tasleson> Interestingly I initially had only initiator, then moved to only access group, then brought the initiator stuff back for targetd :-)
[2014-03-20 06:27] <grover> what's the timeframe for this change?
[2014-03-20 06:27] <tasleson> Well sooner would be better :-)
[2014-03-20 06:27] <fge> :)
[2014-03-20 06:27] <grover> hah ok
[2014-03-20 06:28] <grover> I'll try to get to it soon
[2014-03-20 06:28] <tasleson> My concern is if there is any arrays that don't support access groups outside of targetd and what we would do then.
[2014-03-20 06:28] <tasleson> Gris mentioned turn every initiator into a group on the fly
[2014-03-20 06:28] <fge> Treat every initiator as a group.
[2014-03-20 06:29] <fge> In SAN world, I see no array support initator mask only.
[2014-03-20 06:29] <grover> the plugin would throw an error if a 2nd initiator was added to a group?
[2014-03-20 06:29] <tasleson> fge: Could you supply a patch for targetd plugin that does what you suggest?
[2014-03-20 06:30] <fge> tasleson: will do.
[2014-03-20 06:30] <tasleson> If it works, then targetd doesn't have to change right away
[2014-03-20 06:30] <fge> grover: ErrorNumber.NO_SUPPORT will do.
[2014-03-20 06:31] <tasleson> OK anything else?
[2014-03-20 06:31] <fge> None.
[2014-03-20 06:31] <fge> I am done.
[2014-03-20 06:32] <tasleson> OK, I will get a response out to your email ASAP for the python API changes.
[2014-03-20 06:32] <grover> so for now we're just saying instead of a flag that a plugin doesn't support groups, there won't be a flag but the plugin will return no_support, right?
[2014-03-20 06:32] <grover> and then later targetd will gain support and no longer return that error
[2014-03-20 06:32] <fge> grover: I am about to change LSM plugin to treat every initiator as a group.
[2014-03-20 06:33] <fge> grover: and raise ErrorNumber.NO_SUPPORT if adding 2nd initator to that group.
[2014-03-20 06:33] <tasleson> Well, if we go forward with gris's approach, then every array must support access groups
[2014-03-20 06:33] <fge> grover: that might save some time for you to support access group.
[2014-03-20 06:33] <tasleson> Just in targetd case simplified representation
[2014-03-20 06:34] <fge> that's better.
[2014-03-20 06:34] <grover> ok
[2014-03-20 06:35] <fge> so the aggreement of this is: wait grover to change targetd to expose access group?
[2014-03-20 06:36] <tasleson> Yes, I would like fge to supply patch demonstrating access groups for array that doesn't support them.
[2014-03-20 06:36] <tasleson> That way we will be covered if it shows up for other array
[2014-03-20 06:36] <fge> noted.
[2014-03-20 06:36] <tasleson> We can then add true access group support to targetd if we want later
[2014-03-20 06:37] <fge> so. 1. I provide patches change lsm targetd.py plugin to support access group in workaround way.
[2014-03-20 06:38] <fge> 2. Once grover finished true access group support, I update targetd.py for that.
[2014-03-20 06:39] <grover> I'm happy to update targetd.py in step 2 as well as the array code
[2014-03-20 06:39] <fge> ok. I take step 1 to show possiblity of supporting initiator-only array.
[2014-03-20 06:40] <fge> Are we done?
[2014-03-20 06:40] <tasleson> Yeah, I think so. Thanks everyone!
[2014-03-20 06:40] <fge> Thank you and grover. Have a good night/day/