Bugzilla – Bug 3682
pkg publisher should show mirrors in default listing
Last modified: 2009-03-09 14:26:22 UTC
You need to log in before you can comment on or make changes to this bug.
If I set a mirror using the pkg set-authority -m command and then run pkg authority on the image, the mirror isn't listed. It would be very useful to have this.
pkg authority _authority_ will display any configured mirrors for that authority. Do you have a suggestion for how the output of "pkg authority" might change to display the mirrors? Indenting the mirrors on subsequent lines is possible, but not very useful for standard "grep" uses: $ pkg authority AUTHORITY URL opensolaris.org (preferred) http://ipkg.sfbay/ http://ipkg.central/ sunfreeware.com http://pkg.sunfreeware.com:9000/ $ pkg authority | grep opensolaris opensolaris.org (preferred) http://ipkg.sfbay/
(In reply to comment #1) > pkg authority _authority_ will display any configured mirrors for that > authority. > > Do you have a suggestion for how the output of "pkg authority" might change > to display the mirrors? Indenting the mirrors on subsequent lines is possible, > but not very useful for standard "grep" uses: > > $ pkg authority > AUTHORITY URL > opensolaris.org (preferred) http://ipkg.sfbay/ > http://ipkg.central/ > sunfreeware.com http://pkg.sunfreeware.com:9000/ > > $ pkg authority | grep opensolaris > opensolaris.org (preferred) http://ipkg.sfbay/ Perhaps this? $ pkg authority AUTHORITY TYPE URL opensolaris.org (preferred) origin http://ipkg.sfbay/ opensolaris.org mirror http://ipkg.central/ sunfreeware.com origin http://pkg.sunfreeware.com:9000/ or this? $ pkg authority AUTHORITY URL opensolaris.org (preferred) http://ipkg.sfbay/ opensolaris.org (mirror) http://ipkg.central/ sunfreeware.com http://pkg.sunfreeware.com:9000/ or this? $ pkg authority AUTHORITY URL ENTRY TYPE opensolaris.org (preferred) http://ipkg.sfbay/ (origin) opensolaris.org http://ipkg.central/ (mirror) sunfreeware.com http://pkg.sunfreeware.com:9000/ (origin)
This is what I was expecting. Gives me all the info I need. $ pkg authority AUTHORITY URL opensolaris.org (preferred) http://ipkg.sfbay/ opensolaris.org (mirror) http://ipkg.central/ sunfreeware.com http://pkg.sunfreeware.com:9000/
(In reply to comment #2) > (In reply to comment #1) > > pkg authority _authority_ will display any configured mirrors for that > > authority. > > > > Do you have a suggestion for how the output of "pkg authority" might change > > to display the mirrors? Indenting the mirrors on subsequent lines is possible, > > but not very useful for standard "grep" uses: > > > > $ pkg authority > > AUTHORITY URL > > opensolaris.org (preferred) http://ipkg.sfbay/ > > http://ipkg.central/ > > sunfreeware.com http://pkg.sunfreeware.com:9000/ > > > > $ pkg authority | grep opensolaris > > opensolaris.org (preferred) http://ipkg.sfbay/ > > Perhaps this? > $ pkg authority > AUTHORITY TYPE URL > opensolaris.org (preferred) origin http://ipkg.sfbay/ > opensolaris.org mirror http://ipkg.central/ > sunfreeware.com origin http://pkg.sunfreeware.com:9000/ > > or this? > $ pkg authority > AUTHORITY URL > opensolaris.org (preferred) http://ipkg.sfbay/ > opensolaris.org (mirror) http://ipkg.central/ > sunfreeware.com http://pkg.sunfreeware.com:9000/ > > or this? > $ pkg authority > AUTHORITY URL ENTRY TYPE > opensolaris.org (preferred) http://ipkg.sfbay/ (origin) > opensolaris.org http://ipkg.central/ (mirror) > sunfreeware.com http://pkg.sunfreeware.com:9000/ (origin) A STATUS column would be good to, or to leave room for. Eventually we may mark mirrors as "broken".
> > $ pkg authority > > AUTHORITY TYPE URL > > opensolaris.org (preferred) origin http://ipkg.sfbay/ > > opensolaris.org mirror http://ipkg.central/ > > sunfreeware.com origin http://pkg.sunfreeware.com:9000/ > A STATUS column would be good to, or to leave room for. Eventually we > may mark mirrors as "broken". I think that leads us to something derived from Shawn's first choice: AUTHORITY TYPE STATUS URL opensolaris.org (preferred) origin online http://ipkg.sfbay/ opensolaris.org (preferred) mirror corrupt http://ipkg.central/ sunfreeware.com origin offline http://pkg.sunfreeware.com:9000/ At this point, I believe the "(preferred)" tag should be its own column, rather than a suffix to the authority column. I also wonder if status is the right axis, or if we should be using quality (using corruption rate, uptime, and measured transfer speed as inputs).
(In reply to comment #5) > > > $ pkg authority > > > AUTHORITY TYPE URL > > > opensolaris.org (preferred) origin http://ipkg.sfbay/ > > > opensolaris.org mirror http://ipkg.central/ > > > sunfreeware.com origin http://pkg.sunfreeware.com:9000/ > > > A STATUS column would be good to, or to leave room for. Eventually we > > may mark mirrors as "broken". > > I think that leads us to something derived from Shawn's first choice: > > AUTHORITY TYPE STATUS URL > opensolaris.org (preferred) origin online http://ipkg.sfbay/ > opensolaris.org (preferred) mirror corrupt http://ipkg.central/ > sunfreeware.com origin offline http://pkg.sunfreeware.com:9000/ Is online/offline here an actual indicator of the current status of the authority, or an indicator of how pkg is currently treating it due to errors, etc.? > At this point, I believe the "(preferred)" tag should be its own > column, rather than a suffix to the authority column. I also wonder > if status is the right axis, or if we should be using quality (using > corruption rate, uptime, and measured transfer speed as inputs). I think a simple "high-level status" is preferable as an indicator for "pkg authority". Showing corruption rate, uptime, etc. seems better suited to when a specific authority is provided.
> > AUTHORITY TYPE STATUS URL > > opensolaris.org (preferred) origin online http://ipkg.sfbay/ > > opensolaris.org (preferred) mirror corrupt http://ipkg.central/ > > sunfreeware.com origin offline http://pkg.sunfreeware.com:9000/ > > Is online/offline here an actual indicator of the current status of the > authority, or an indicator of how pkg is currently treating it due to errors, > etc.? The latter. It's calculated from whatever persistent record we have of the mirror's behaviour. > > At this point, I believe the "(preferred)" tag should be its own > > column, rather than a suffix to the authority column. I also wonder > > if status is the right axis, or if we should be using quality (using > > corruption rate, uptime, and measured transfer speed as inputs). > > I think a simple "high-level status" is preferable as an indicator for "pkg > authority". > > Showing corruption rate, uptime, etc. seems better suited to when a specific > authority is provided. Sorry: to be clear, I meant "should we have a STATE sympathetic with smf(5) states (online, offline, degraded), or a QUALITY (low, medium, high), which would be deliberately distinct?" Both would be some calculated result from the inputs I mentioned; detailed display we would handle as you say.
(In reply to comment #7) > > > At this point, I believe the "(preferred)" tag should be its own > > > column, rather than a suffix to the authority column. I also wonder > > > if status is the right axis, or if we should be using quality (using > > > corruption rate, uptime, and measured transfer speed as inputs). > > > > I think a simple "high-level status" is preferable as an indicator for "pkg > > authority". > > > > Showing corruption rate, uptime, etc. seems better suited to when a specific > > authority is provided. > > Sorry: to be clear, I meant "should we have a STATE sympathetic with smf(5) > states (online, offline, degraded), or a QUALITY (low, medium, high), which > would be deliberately distinct?" Both would be some calculated result from the > inputs I mentioned; detailed display we would handle as you say. low, medium, and high doesn't seem as meaningful to me as online, offline, degraded. I'm assuming low = offline, medium = degraded, and high = online? The difficulty will likely be in determining the thresholds for those.
FWIW, I like the idea of having online, offline, corrupt rather than the other scheme that Stephen suggested. Though, I have a little bit of an issue with 'corrupt' - would this be client side corruption, or server side, or both? Is the only option to either refresh the cache, or remove the mirror?
(In reply to comment #9) > FWIW, I like the idea of having online, offline, corrupt rather than the other > scheme that Stephen suggested. Though, I have a little bit of an issue with > 'corrupt' - would this be client side corruption, or server side, or both? Is > the only option to either refresh the cache, or remove the mirror? That's why 'degraded' is probably a better option than 'corrupt'; because it could be a bad route to a specific mirror or it could be the mirror itself. Removing the mirror from the automatic selection list seems like the only sane option. I'm not sure I understand your "refresh the cache" comment.
Shawn: probably in the sense of rebuild-index rather than anything else ie. something on your system has screwed up and a rebuild is required. (I don't know what occasion would cause the user to take this action)
(In reply to comment #11) > Shawn: probably in the sense of rebuild-index rather than anything else ie. > something on your system has screwed up and a rebuild is required. (I don't > know what occasion would cause the user to take this action) That would be completely unrelated to this change as far as I know. The index you speak of is strictly for search capability.
Since the authority API implementation will require changing how authority information is obtained, it seems logical to make this change at the same time.
Work in progress.
Implemented in changeset 926 / 6ee411c9026af426a657cb1f5e4b73c14c2e1112.