Erik Nordmark wrote: > On 05/19/10 04:37 AM, James Carlson wrote: > >> It'd be nice if some of those broader plans were included somewhere for >> review or at least for reference. It is indeed hard for ARC members and >> other participants to make any sense out of the materials submitted for >> review if there are crucial parts that are not included. > > The first order issue is that AI, which has been underway for years, > isn't available for review yet. The network configuration roadmap and > its projects are still seeing significant change. > > If AI had been presented to the ARC, I could put together an > overview/umbrella presentation of the network configuration projects > that we are discussing. > > But I don't know if that is useful given that there isn't similar > material for AI available to the ARC.
I see. >> The quality of the review and the eventual product both suffer. > > The ARC isn't the only place where things get reviewed, hence I'm not > too concerned about the product quality in the space of network > configuration. The ARC is where the architecture of projects for OpenSolaris is supposed to be reviewed. If changes and plans are also reviewed elsewhere, that's great, but I don't think such reviews are in any way a substitute ... as long as the ARC still exists and serves some useful function. On the other hand, I completely agree that without the background information, it's not possible for the ARC to "add value." >>> I don't understand how speculating on the organizational structure at >>> Oracle is part of the ARC process. >> >> I'm talking about the projects and the relationships between them, which >> are the items under review by the ARC. I neither know nor care about >> Oracle's internal structure. > > Sorry, but you were referring to there being separate groups (and such > groups consists of people AFAIK) not working together, when in fact that > doesn't match the current organization. If it helps, I'm happy running s/group/project team/g on any of the previous statements I made. Again, I neither know nor care about Oracle's internal structure. >> One of the important jobs of the ARC is to make sure that (as much as as >> possible) projects are working together in a common direction. > > Had your comment been "have you coordinated with the XYZ project" it > would have been different. However, the NWAM project is done apart from > any followup bug fixing, hence it isn't useful to coordinate with that > project. > > Moving forward we have a set of work in the area of networking > configuration that spans the range from how servers are typically > configured to the problems NWAM set out to solve. The reason to > structure things that way is exactly to avoid the problems you are > concerned about. When NWAM first came for review (and then again when it came for review of Phase 1), PSARC members asked the project team why physical:default was still present, and why NWAM was just an "option," and indeed _not_ even the default one at that. The answer was that NWAM would eventually be the only way to configure the system, and that the project team recognized that it was less good to have two separate mechanisms, but that this would persist for some time. At least until NWAM (in Phase 2) eventually grew the features necessary for enterprise-scale operation. Then, in the Phase 1 review, the NWAM project team introduced "profiles" as a key concept in the NWAM architecture which (still, at that time) was intended to be the future way for configuring interfaces, and which the ARC members were told was consistent with the SMF goals. If I'm reading what you've written above correctly, it seems that you're saying that the future architecture won't necessarily be what was originally reviewed -- that there is no "Phase 2" and NWAM won't be the sole mechanism -- and that some higher level work is being done. But that there's no ARC material available at the moment that describes this. The hard part for the folks on the ARC list, though, is to figure out how the proposal here eventually morphs into that future architecture. I know I don't see it. As described in the last opinion, we are (or were) waiting for future NWAM phases (that I now assume are no longer happening): http://arc.opensolaris.org/caselog/PSARC/2008/532/opinion.txt >> The fact >> that there were clear statements in this thread from project team >> members saying that they didn't want to have to understand NWAM profiles >> certainly makes it appear that project alignment is one of the problems. >> >> http://www.mail-archive.com/[email protected]/msg00616.html >> http://www.mail-archive.com/[email protected]/msg00626.html >> http://www.mail-archive.com/[email protected]/msg00605.html > > I don't see anything on those emails where Mark says or implies that he > doesn't want to have to understand NWAM profiles. Hence I think you owe > Mark an apology. Here's what he wrote in that very first message I cited: "And the Install team would prefer to not have to understand the details of an NWAM profile to create one themselves. " I don't believe I've written anything that requires that I give an apology to Mark. But if he is indeed offended, I hope that he'll speak up about it, at least privately, and I'll be happy to reply. Certainly no offense of any sort was intended. My interpretation of that statement was that even if profiles are a core concept in NWAM, dependence on them would be unwise for another project. The implication is that either they're too complex for the task at hand, or too unstable, or perhaps that NWAM itself will be supplanted. All of those seem possible, I don't know which is the case, but there's at least a lack of clarity on how these things align. Thus, I think the earlier questions from Darren and others asking why NWAM isn't part of this answer are right on the mark. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ opensolaris-arc mailing list [email protected]
