PeterB Posted June 13, 2015 Share Posted June 13, 2015 A clear exception which SHOULD stop a release would be any issue that impacts data integrity ... but that's not the case with the Docker issue. Perhaps it's not a 'show-stopper', but after having to edit my containers for a fifth time today (five power cuts, and still seven hours to go to midnight)), it is very frustrating. Quote Link to comment
CHBMB Posted June 13, 2015 Share Posted June 13, 2015 A clear exception which SHOULD stop a release would be any issue that impacts data integrity ... but that's not the case with the Docker issue. Perhaps it's not a 'show-stopper', but after having to edit my containers for a fifth time today (five power cuts, and still seven hours to go to midnight)), it is very frustrating. Man, I'd break and roll back to RC5 if I were in your position. Quote Link to comment
PeterB Posted June 13, 2015 Share Posted June 13, 2015 Perhaps it's not a 'show-stopper', but after having to edit my containers for a fifth time today (five power cuts, and still seven hours to go to midnight)), it is very frustrating. Man, I'd break and roll back to RC5 if I were in your position. A possibility, indeed. However, if v6 final isn't held for a resolution to this problem, I may then be left on rc5 while others are running the final release. Quote Link to comment
CHBMB Posted June 13, 2015 Share Posted June 13, 2015 Perhaps it's not a 'show-stopper', but after having to edit my containers for a fifth time today (five power cuts, and still seven hours to go to midnight)), it is very frustrating. Man, I'd break and roll back to RC5 if I were in your position. A possibility, indeed. However, if v6 final isn't held for a resolution to this problem, I may then be left on rc5 while others are running the final release. Tom has already said there'll be a RC6a or RC7 (Not sure what determines which label) I have faith they'll fix it. And a rose by any other name is still a rose... If 6.0 final doesn't work for me then I'm sure LimeTech won't just forget the issue, there'll be a 6.0.1 or something. Worst case, I stop on RC5 but to be fair up until RC6 the betas from 12 onwards and all the other RCs have been fine. Quote Link to comment
garycase Posted June 13, 2015 Share Posted June 13, 2015 Perhaps it's not a 'show-stopper', but after having to edit my containers for a fifth time today (five power cuts, and still seven hours to go to midnight)), it is very frustrating. I just noticed the RC6 release thread already has 12 pages of comments, mostly on this issue => so clearly it's still causing a lot of problems. Given that once v6.0 is released (and thus listed as the "Stable" release) there will likely be a lot of folks moving to it, I'm sure LT doesn't want a big influx of Docker issues with all the new folks using Dockers for the first time. Much as I'd hate to see yet-another missed release date, I'm beginning to think this issue might just be significant enough to justify that if necessary. If knowledgeable users have to do this ... .. Worst case, I stop on RC5 ... ... then I don't think LT wants a big influx of new Docker users wondering why they're having this issue. I hate to think how much hair is being pulled out at LimeTech this weekend over this ... but I suspect it WILL be resolved very soon. If nothing else, then the forthcoming RC6a/RC7 will hopefully include a workaround that minimizes the likelihood of the issue [Perhaps a built-in DNS default to the Google DNS server, as was discussed in the RC6 thread]. Tom and crew are clearly working VERY hard to get this resolved ... ... Bottom line is this: we'll be generating a rc6a or maybe rc7 ... I agree with CHBMB that ... ... I'm sure LimeTech won't just forget the issue, there'll be a 6.0.1 or something. ... but clearly it would be nice if the first "Stable" release didn't have this outstanding issue. Quote Link to comment
jumperalex Posted June 13, 2015 Share Posted June 13, 2015 Well in fairness a LOT of those posts are from the same set of people all working furiously to figure out the problem. And it seems the cause and solution have been found per Tom's post. So maybe not delayed, and if so, maybe not by much. [fingers crossed] Quote Link to comment
CHBMB Posted June 13, 2015 Share Posted June 13, 2015 Looking on the bright side, I think this release has helped nail down the problem and it's my impression that LimeTech now completely understands what's actually happening, much easier to fix or work around something when you know what's causing it. Even if final release has a "hackish" work around, the fact that it's now so easy to update Unraid with the plugins system a further sub-release of 6.0.1 is no big issue. I have faith it'll all come out in the wash. Linux and Windows still operates on a periodic update with desktop OS's so I don't see any real difference here. Quote Link to comment
garycase Posted June 13, 2015 Share Posted June 13, 2015 Yes, that's true ... but clearly it IS still an issue. It DOES seem like LT has a handle on the root cause, and just need to determine which of the various mitigations will work the best. I suspect we'll see an RC6a/RC7 VERY soon ... and as long as that resolves the issue it will likely become v6.0 If that new RC is released today, so there's at least 48 hours of "cooking time" for it to be tested by those who have been experiencing the issue, then v6.0 may still be on schedule. Hopefully that's how this will play out (fingers also crossed) Quote Link to comment
garycase Posted June 13, 2015 Share Posted June 13, 2015 ... Even if final release has a "hackish" work around, the fact that it's now so easy to update Unraid with the plugins system a further sub-release of 6.0.1 is no big issue. Agree the built-in "Update" button makes this much easier. But clearly it'd be far better if this wasn't an issue at all in v6.0 There are still a fair number of folks who won't upgrade to v6.0 until it's shown as the "Stable" release ... and many of those aren't active forum participants and won't necessarily be knowledgeable users who can easily implement the known workarounds for this issue. These folks will also be moving to Dockers for the first time ... so it would clearly be better if there wasn't a known issue with Docker connectivity in the release. One thing that has always been true in the past: When Tom designates a release as "Stable", it IS stable. This is a record that would be nice to maintain ... and I think it's VERY close to being true for RC6, with the sole exception of this issue, so if necessary a day or two's slip is probably preferable to breaking this record. Quote Link to comment
sparklyballs Posted June 13, 2015 Share Posted June 13, 2015 ... Even if final release has a "hackish" work around, the fact that it's now so easy to update Unraid with the plugins system a further sub-release of 6.0.1 is no big issue. Agree the built-in "Update" button makes this much easier. But clearly it'd be far better if this wasn't an issue at all in v6.0 There are still a fair number of folks who won't upgrade to v6.0 until it's shown as the "Stable" release ... and many of those aren't active forum participants and won't necessarily be knowledgeable users who can easily implement the known workarounds for this issue. These folks will also be moving to Dockers for the first time ... so it would clearly be better if there wasn't a known issue with Docker connectivity in the release. One thing that has always been true in the past: When Tom designates a release as "Stable", it IS stable. This is a record that would be nice to maintain ... and I think it's VERY close to being true for RC6, with the sole exception of this issue, so if necessary a day or two's slip is probably preferable to breaking this record. it does need reiterating again that this is a docker bug that LT are trying to find a workaround for. Quote Link to comment
bkastner Posted June 13, 2015 Share Posted June 13, 2015 ... Even if final release has a "hackish" work around, the fact that it's now so easy to update Unraid with the plugins system a further sub-release of 6.0.1 is no big issue. Agree the built-in "Update" button makes this much easier. But clearly it'd be far better if this wasn't an issue at all in v6.0 There are still a fair number of folks who won't upgrade to v6.0 until it's shown as the "Stable" release ... and many of those aren't active forum participants and won't necessarily be knowledgeable users who can easily implement the known workarounds for this issue. These folks will also be moving to Dockers for the first time ... so it would clearly be better if there wasn't a known issue with Docker connectivity in the release. One thing that has always been true in the past: When Tom designates a release as "Stable", it IS stable. This is a record that would be nice to maintain ... and I think it's VERY close to being true for RC6, with the sole exception of this issue, so if necessary a day or two's slip is probably preferable to breaking this record. I agree. I would think it's much more important to get it right, than on time (where on time equals an arbitrary date LT has decided to announce). After a year and a half of development it seems sort of stupid to rush it out the door now when another day or two could confirm the resolution of an issue that will likely impact many new users (based on the assumption that plugins are a thing of the past in 6.0 and many/most will likely want to try Docker as part of the 6.0 upgrade). Quote Link to comment
bkastner Posted June 13, 2015 Share Posted June 13, 2015 it does need reiterating again that this is a docker bug that LT are trying to find a workaround for. True, but essentially irrelevant. Perception is reality. The perception is that LT's plugin replacement (i.e. Dockers) are not working correctly, and the blame will sit with LT - not Docker. It's the risk you take by including other vendor's products into yours as part of your core offering. Given that there is a proposed workaround that could mitigate this, I think it makes a lot of sense to make sure that workaround works to ensure a positive end user experience for people testing out 6.0 for the first time (because it's listed as final). If you were a semi-technical person (i.e. enough to have invested in UnRAID) and you chose to upgrade to 6.0 and leverage the highly touted Dockers for plugin replacements, after hours of frustration and hair pulling to get your add-ons working again like they did before, how reassured would you be to have LT say "it's not our fault, it's Dockers". I am sure that is going to make everything so much better. Quote Link to comment
sparklyballs Posted June 13, 2015 Share Posted June 13, 2015 it does need reiterating again that this is a docker bug that LT are trying to find a workaround for. True, but essentially irrelevant. Perception is reality. The perception is that LT's plugin replacement (i.e. Dockers) are not working correctly, and the blame will sit with LT - not Docker. It's the risk you take by including other vendor's products into yours as part of your core offering. Given that there is a proposed workaround that could mitigate this, I think it makes a lot of sense to make sure that workaround works to ensure a positive end user experience for people testing out 6.0 for the first time (because it's listed as final). If you were a semi-technical person (i.e. enough to have invested in UnRAID) and you chose to upgrade to 6.0 and leverage the highly touted Dockers for plugin replacements, after hours of frustration and hair pulling to get your add-ons working again like they did before, how reassured would you be to have LT say "it's not our fault, it's Dockers". I am sure that is going to make everything so much better. saying it's docker's bug does not neccessarily mean "it's not our fault, it's Dockers". that's a hell of an extrapolation. i see no reason that 6.0 final to be held up PROVIDING it's listed as a known issue and the workaround offerred in lieu of something more permanent. Quote Link to comment
bkastner Posted June 13, 2015 Share Posted June 13, 2015 it does need reiterating again that this is a docker bug that LT are trying to find a workaround for. True, but essentially irrelevant. Perception is reality. The perception is that LT's plugin replacement (i.e. Dockers) are not working correctly, and the blame will sit with LT - not Docker. It's the risk you take by including other vendor's products into yours as part of your core offering. Given that there is a proposed workaround that could mitigate this, I think it makes a lot of sense to make sure that workaround works to ensure a positive end user experience for people testing out 6.0 for the first time (because it's listed as final). If you were a semi-technical person (i.e. enough to have invested in UnRAID) and you chose to upgrade to 6.0 and leverage the highly touted Dockers for plugin replacements, after hours of frustration and hair pulling to get your add-ons working again like they did before, how reassured would you be to have LT say "it's not our fault, it's Dockers". I am sure that is going to make everything so much better. saying it's docker's bug does not neccessarily mean "it's not our fault, it's Dockers". that's a hell of an extrapolation. i see no reason that 6.0 final to be held up PROVIDING it's listed as a known issue and the workaround offerred in lieu of something more permanent. I didn't think it was that much of an extrapolation, but again, I guess that's perception. However, I don't agree with your last statement - only because again, those who follow/participate in the forums are likely fine with this workaround, but with 6.0 being marked stable / final, you are going to get a ton of non-technical people trying it out, and you can pretty much guarantee that a large percentage will either not read that caveat, understand it, or be willing/able to implement it. They are looking to UnRAID to take the complexity out of the equation and so it makes far more sense for LT to manage this themselves to eliminate the issue (either completely, or via workaround) than it does to trust the masses understand the issue and be able to address it. Again, it comes down to perception. (I seem to be on a theme with this at the moment). Quote Link to comment
aptalca Posted June 13, 2015 Share Posted June 13, 2015 Now, where did I leave my pitchfork? Just kidding I'm not even affected by it I'm going to chuckle if it hits you with final release! Hehe, only joking wouldn't wish ill on a fellow forumite. Damn it!!! Updated to RC6, rebooted and bam. My dockers cannot resolve dns. Where is that stupid pitchfork??? I had the dns issue when I was messing with VMs maybe back in RC2 or something. Since I disabled VMs through the VM Manager settings, I had not had any issues. With RC6 I do. Quote Link to comment
garycase Posted June 13, 2015 Share Posted June 13, 2015 it does need reiterating again that this is a docker bug that LT are trying to find a workaround for. True, but essentially irrelevant. Perception is reality. Definitely true ... the user doesn't care WHERE the problem is, only that there's a problem. The perception will be simple: "I upgraded to the "Stable" release and now I'm having this problem." It's pretty clear they aren't going to care that it's (a) a documented "bug" in the release notes; (b) not Limetech's fault because it's a Docker bug; etc. ... i see no reason that 6.0 final to be held up PROVIDING it's listed as a known issue ... My original thought was the same, until I read through the # of folks still experiencing the issue and thought about the simple fact that everyone who upgrades to the "Stable" release is now going to be using Dockers for the first time ... so are very likely to encounter this issue. ... and many of these folks are not going to be regular forum participants or necessarily have the technical competence or willingness to read through caveats and implement workarounds. I agree with bknaster's point ... ... They are looking to UnRAID to take the complexity out of the equation and so it makes far more sense for LT to manage this themselves to eliminate the issue ... Quote Link to comment
sparklyballs Posted June 13, 2015 Share Posted June 13, 2015 My original thought was the same, until I read through the # of folks still experiencing the issue a workaround has elimated the issue for me, it's not ideal because it's at the container level, but when this compile for a container has finished i'm going to test the permissions fix posted in the release annoucement thread and then apply the dns fix to docker.cfg. if that fixes the issue then it's a fairly trivial thing to implement by LT. now testing between now and release is the key though. Quote Link to comment
garycase Posted June 13, 2015 Share Posted June 13, 2015 My original thought was the same, until I read through the # of folks still experiencing the issue a workaround has elimated the issue for me, it's not ideal because it's at the container level, but when this compile for a container has finished i'm going to test the permissions fix posted in the release annoucement thread and then apply the dns fix to docker.cfg. if that fixes the issue then it's a fairly trivial thing to implement by LT. now testing between now and release is the key though. Yes, I saw Eric's post and had the same thought. If that in fact resolves this, they need to get out an RC6a pronto, so folks can test it for a couple days and confirm the issue "goes away". I do think there needs to be a minimum of 48 hours between releasing the RC and changing its designation to "final" ... so time is indeed getting short. Quote Link to comment
sparklyballs Posted June 13, 2015 Share Posted June 13, 2015 After a misunderstanding of the permissions fix for dns issues with containers, and on a couple of reboots now, this is working for me. it's a kludge in lieu of LT making it a on runtime thing... take out any --dns fixes at container level or in the docker.cfg (if you have any of course) then reboot and after docker has started enter the following on the unraid command line. find /var/lib/docker/containers/ -name resolv.conf -maxdepth 2 -exec chmod 644 {} + containers are now able to resolve dns and have network connectivity Quote Link to comment
CHBMB Posted June 13, 2015 Share Posted June 13, 2015 I've been thinking, I'll try and follow on twitter, but on nights in the UK, time difference etc. It's be great if LimeTech did a Q & A session on the Irc chatroom or something as I'd love to know a bit more about behind the scenes... Quote Link to comment
sparklyballs Posted June 13, 2015 Share Posted June 13, 2015 i've just noticed something. the OS in UnRAID Server OS 6 is that the official title now ? Quote Link to comment
jonp Posted June 13, 2015 Author Share Posted June 13, 2015 i've just noticed something. the OS in UnRAID Server OS 6 is that the official title now ? The official title of the product is unRAID Server OS. The version is injected after "OS". Clearly there are plenty of shorthand references to it though, my favorite being just unRAID 6. Quote Link to comment
PeterB Posted June 13, 2015 Share Posted June 13, 2015 then reboot and after docker has started enter the following on the unraid command line. find /var/lib/docker/containers/ -name resolv.conf -maxdepth 2 -exec chmod 644 {} + containers are now able to resolve dns and have network connectivity So, it's a permissions issue on the resolv.conf file in the docker images? Is this a one-time fix, or does it have to be applied on every reboot? Interesting that two of my dockers already have 644 permissions on the file. I also note that all but but one of my docker images also have a resolv.conf.hash file. Quote Link to comment
eschultz Posted June 14, 2015 Share Posted June 14, 2015 rc6a has been released and should finally fix the Docker DNS issues. No need to run that 'find' command -- that was just for testing. To restore proper operation of your containers after upgrading to rc6a: 1. Remove all places you might have added --dns=<ip-address> switch: docker.cfg file and/or "Extra parameters" on container edit page. If you made changes to docker.cfg then restart Docker. 2. For each container bring up edit page, click save. Note this will also "update" the image. That's it, communication with outside world should be restored. Quote Link to comment
garycase Posted June 14, 2015 Share Posted June 14, 2015 Well done. The key thing is that new folks migrating to v6 and setting up Dockers for the first time won't encounter this at all, since they won't have made any of those mods that have to be removed first ... and it was released early enough that you can have a 48-hr "burn-in" for the RC and still make the 15th release date 8) Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.