Mike Christie wrote:
> Doron Shoham wrote:
>> Mike Christie wrote:
>>> Doron Shoham wrote:
>>>> Divide node parameters into 3 categories:
>>>>  a. Immutable - properties that are not allowed to change at all.
>>>>  b. Immediate - properties that are allowed to change and take effect
>>>> immediately.
>>>>  c. Deferred  - properties that are allowed to change but will take
>>>> effect only next
>>>>  session.
>>>> @@ -588,13 +588,22 @@ static int idbm_verify_param(recinfo_t *info,
>>>> char *name)
>>>>              continue;
>>>>          log_debug(7, "verify %s %d\n", name, info[i].can_modify);
>>>> -        if (info[i].can_modify)
>>>> +        if (info[i].can_modify == ATTR_IMMEDIATE)
>>>>              return 0;
>>>> -        else {
>>>> -            log_error("Cannot modify %s. It is used to look up "
>>>> -                  "the record and cannot be changed.", name);
>>>> -            return EINVAL;
>>>> +        else if (info[i].can_modify == ATTR_DEFERRED) {
>>>> +            if (is_active == 0)
>>>> +                return 0;
>>>> +            else {
>>>> +                log_error("Cannot modify %s. Please logout before
>>>> modifing it", name);
>>>> +                return EINVAL;
>>>> +            }
>>>> +        }
>>>> +        else if (info[i].can_modify == ATTR_IMMUTABLE) {
>>>> +            log_error("Cannot modify %s. This value is immutable "
>>>> +            "and cannot be modified", name);
>>>> +                        return EINVAL;
>>>>          }
>>> I was thinking about this and there is no reason that we cannot update
>>> the values that are marked ATTR_DEFERRED when a session is logged in.
>>> The description of C) in the first snippet and what we do in
>>> idbm_verify_param do not match up, because idbm_verify_param is not
>>> going to let you update the value if we are logged in. Maybe we just
>>> want to print a warning letting the user know that they have to relogin
>>> to use the new value.
>> Yes, you are right.
>> The description should have been something like:
>> Deferred - properties that are allowed to be changed only while
>> session is not active. They will take effect next session.
>> If we let people to change them while in active session it can be
>> confusing - after the change, if someone will query the node properties
>> he will see the new parameters while these parameters are not
>> the "actual" parameters which the session is used.
> I think this is fine because the node record values are what is stored 
> in the db. It is not supposed to be what we are using now. session mode 
> should display the values we negotiated for and what was requested.
> Also, if you are doing iscsi boot you will never be able to change a 
> value for the session used for root.

When using iscsi boot, I think that changing the node parameters 
while logged in will not effect next session
(you will have to change the default iscsi boot parameters).

Another solution is to add -f flag (force).
Using this flag will change the parameter while in active session -
still it will display a warning message that the change will only
effect the next session.

>> And another problem is, again, if someone changes the
>> transport type while logged in, bad things happen.
> We can make it so the transport type is not changable while logged in. 
> We do that today already in the git tree.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to