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.

> 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