In-progress development discussions
- libnwam_ncp.c could do with a bit more refactoring
it could utilize the generic object manipulation functions in libnwam_object.c more. - May have to change bfu script to import the network/physical manifest.
Currently, the manifest-import runs after nwam starts. Thus, after bfu and reboot, nwamd will not run as netadm user and fail.- SystemV packages have the postinstall script. What about IPS packages? How can OpenSolaris import the new manifest before the system/manifest-import service starts?
- Tony Nguyen's suggestion to follow the same procedure as network/ipfilter. Quoted verbatim:
I suggest looking at how network/ipfilter handles a similar configuration upgrade scenario, migrating existing ipf settings to the new repository properties. A quick overview: Versioning: network/ipfilter manifest defines the new firewall_config_default/version property to store the current configuration version. The property has a default value of 0 which gets updated after every successful upgrade. The start method has a new hard-coded version in its method script which it compares to the current version (value in the property) to determine whether an upgrade is necessary (this also allows us to upgrade between different versions). Starting logic: network/ipfilter start method performs an upgrade if - aforementioned version property exists - and the version value is a down-rev If the version property doesn't exist, the service needs to wait for manifest-import and simply returns 0 (quasi-online state). Manifest-import will request a service refresh once it completed importing the new manifest. The service's refresh method determines if an upgrade is necessary using the same logic (though it's guaranteed to have the new property), and simply does 'svcadm restart' to request the start method to perform the upgrade. It is not perfect but seems to work fine for network/ipfilter. We're also contemplating enhancement to SMF to simplify the upgrade use cases, perhaps an upgrade that prior to start method if an upgrade is necessary. Stay tuned. cheers, -tony
We will use the nwamd/upgraded property to determine whether the Phase 1 manifest has been imported or not.
- On boot, the condition check should wait until interfaces are up and DHCP lease acquired.
- Current solution will be to put a guard so that the condition check only happens after at least one interface is up and DHCP lease acquired.
- Future solutions will be check if the location being activated requires DHCP or not. If nameservices are manually configured, then this location can be activated even if the interfaces are not up or DHCP lease acquired. If, however, nameservices are to be configured automatically via DHCP, then the location activation should wait.
- Also, even if the interfaces are configured to have static IPs, DHCPINFORM must be performed when the interfaces are plumbed so that nameservices can be configured automatically.
- Selecting NCUs to be activated
- activation-mode manual ncus are considered independently of prioritized; that is, if both prioritized and manual ncus exist, the highest priority ncu that can be activated will be, regardless of whether or not any manual ncus have been activated.
- The scenario where the user has prioritized a wireless link over wired link(s) has potential for annoyance: if nwamd needs additional information to bring up the (preferred) wireless link, such as a wlan selection, it will go ahead and bring up the wired link (if possible). This might in fact be the user's intent: my preferred wlan isn't available, so I'll use wired instead. In that case, nwam's continued prodding for (nwamd sending repeated events) a wlan selection could become annoying.
- For phase 1, users will just need to avoid this situation: they can prioritize wired over wireless, and use whether or not a cable is plugged in to choose between the two; or they can simply make the ncus manually activated and switch as needed.
- A future approach to solving this could be "layered" ncus, where a specific wlan connection is a sort of virtual ncu that sits on top of a physical (wireless) link--somewhat analogous to a vlan. The prioritized activation could be based on the wlan ncu, rather than simply the presence of the wireless link.
- NCU states: uninitialized vs. initialized
Need to work out how exactly state is mapped for link NCUs. Proposal:- uninitialized: nwamd has read in the configuration, but the configured ncu has not been mapped to a real entity. Non-physical link ncus should pass straight through this state without stopping. Physical link ncus remain in this state until a device is found in the system that maps to the ncu.
- initialized: nwamd has read in the configuration, and any associated device is present. The set of initialized ncus whose activation-mode is active make up the list that is walked when looking for ncus to select for nwam-initiated activation.
Some open questions: - What exactly sends an ncu into maintenance state?
- Once in maintenance state, is user intervention required to recover, or can nwamd determine automatically that whatever condition sent it to maintenance is no longer a problem? This answer really depends on the answer to the previous question...
- name vs. typedname
Some functions expect name (bge0) while others expect typedname (datalink:bge0 or ip:bge0). This needs to be cleaned up, (at the very least comment what's the expected name). A better solution would be to pass around typedname and only convert to name when it is absolutely necessary (like plumbing or getting dhcp address).- Also, the nwamd_ncu_t structure (pointed to by object_data in nwamd_object_t) stores the type and name (not typedname) of ncus. If these values are kept in that structure, there's no need for nwam_ncu_typed_name_to_name() function calls.