MultiCast deployment doesn't take the rest of the listed machines when an obstable occurs
-
Thats kinda frustrating as I sometimes multicast to a group of computers except a few that I don’t want to have the image deployed.
I’d then have to wait for the task to complete from that single computer, multicast to the group, remove that single computer from the task.Giving an error should be well enough, but preventing the rest of the list is a bug imo. the machines being tasked before the “problem” machine are stilled queued, so according to your views even that is a bug.
-
if there are computers in a group that you don’t want the image deployed to, why would you have them in the group when you create the task?
-
Because they need to belong in that group of computers on a more regular basis. The need to be deployed just like the others in the group… but on a less rare occasion I don’t want one or more machines to be deployed while the others in the group do, and it’s random which machine(s) in the group are taken out of deployment.
Imo it should be up to the person who deploys which computers should get a new image, then take the appropriate measures if one or more computer fails to be scheduled.
-
Carsten,
You methodology is wrong. FOG has always had the position, if you will, that if a system is in a task, a second task cannot and should not be tasked again.
I’ve made the corrections to fail out all of the systems in a group if one or more of the systems within the group are already a part of a task. This way, you don’t have pc1 and pc2 in a tasking that can’t be started.
-
It’s not about methodology, but the way some things are needed to work. I’m sad to see, what could have been a good feature (simple to make for that matter), has been removed. It’s not like a big red frame saying “This computer failed due to X” doesn’t appear in the deployers screen.
-
the correct methodology for only imaging a certain number of computers in a group is to add only those that need to be imaged to a temporary group. there is no limit to the number of groups a host can be part of
-
I hear you.
I can’t do much about it as you don’t want to make it into a feature.
It would have been nice if you could see the bigger picture. -
Carsten,
I can tell you from personal experience that this development team has gone far above and beyond even what could be reasonably expected from PAID support. When you say that this “feature” is “simple to make for that matter”, it’s OPEN SOURCE - do it yourself.
Andy
-
Andy
What you fail to realize is that diy-hacks into a product needs to be maintained for every single upgrade whether it’s a bug fix upgrade or a major feature upgrade.
What you also fail to see is that this is a bug report which can tilt in either direction.
And where would an Open source project be without the community reporting bugs?Lastly I can’t see why you had the need to post your post.
-
Carsten,
First, and foremost, the particular use case that you’re requiring is not the fault of mine.
You did present a bug that I have now corrected for.
I am not going to code things for your particular use case as that is not how it “should” work whether you think so or not.
The bug that you reported (while this wasn’t your intent) was that if any one of the hosts in the group task are in a task, the whole of the tasking ought to fail. This is the proper, and expected action.
If you would like this functionality in your particular version of FOG, by all means, do it. I’m straight up telling you that I’m not going to add in a, in my eyes, useless feature as I can see others creating a tasking and not understanding why that one system isn’t being imaged with the rest when the expected action is of that type.
If you do code in this element, post it here so others who may feel it’s a useful “feature” can see and learn.
While you’re correct that the changes you make will be overwritten on updates, if you make a backup of the files you need changed, we can make sure things work out for you.
Understand that I’ve done a TON for this community and not only from development, but basic support as well.
I most certainly do “see the big picture” which is kind of why I don’t think this is a useful “feature” to be coded in.
I have a development team whom I believe “see the big picture” as well.
When you state “It would have been nice if you could see the bigger picture” I think it’s quite condescending to the FOG Project team as a whole, and I think this is where tamatech’s message is coming from. He knows, first hand, how much work we’ve all been putting towards making FOG a “good” program free of charge. While we do strive to make it better, we’re not always going to add things simple because there’s a thought or request to it.
-
As I said before, I hear you, as in I understand what you’re saying, you won’t add this feature.
With a reference to the “the big picture” I’m refering to the subject/problem (it should probably have written “my big…” instead of “the…”) If it was understood differently or negatively I appologize that was not the intention, reading through the thread again it could look like it, but as I said, it wasn’t the intention.
Making core changes to an application is not something I’m willing to do any longer.
I’ve tried that, lost the documentation and can’t upgrade without having to restart the whole hack.And I know what you’re going through, coding/support/documentation etc. to the OSS commnunity, it’s not a stranger to me.
just fyi:
[quote]
I can see others creating a tasking and not understanding why that one system isn’t being imaged with the rest when the expected action is of that type
[/quote]
A big red (pink?) warning appears on the screen when a client fails.
