Jira (BOLT-338) Local transport for orchestrator
Title: Message Title Alex Dreyer updated an issue Puppet Task Runner / BOLT-338 Local transport for orchestrator Change By: Alex Dreyer Sprint: Bolt Ready for Grooming Add Comment This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-338) Local transport for orchestrator
Title: Message Title Alex Dreyer updated an issue Puppet Task Runner / BOLT-338 Local transport for orchestrator Change By: Alex Dreyer Executing tasks locally is a powerful method of extending the plan language without writing ruby. Currently bolt has to connect over a normal transport to execute local tasks. Instead bolt should have a special local transport that can be used.Users can target the local transport with the bare string "localhost"Users can target localhost with the protocol 'local'. The rest of the uri will be ignored.Implementation:Windows and linux code should be kept in separate classes with the executor deciding which version to load/use.The Inventory should be responsible for handling the host named 'localhost' and returning a host with the local transport.Questions:Should the transport copy task files before execution to make it more useful for iteration during task development? Eventually we may want both options what should we default to or implement first?Should linux and windows shell implementations be separate tickets? Add Comment This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574)
Jira (BOLT-338) Local transport for orchestrator
Title: Message Title Alex Dreyer updated an issue Puppet Task Runner / BOLT-338 Local transport for orchestrator Change By: Alex Dreyer Executing tasks locally is a powerful method of extending the plan language without writing ruby. Currently bolt has to connect over a normal transport to execute local tasks. Instead bolt should have a special local transport that can be used.Users can target the local transport with the bare string "localhost"Users can target localhost with the protocol 'local'. The rest of the uri will be ignored.Implementation:Windows and linux code should be kept in separate classes with the executor deciding which version to load/use.The Inventory should be responsible for handling the host named 'localhost' and returning a host with the local transport.Questions:Should the transport copy task files before execution to make it more useful for iteration during task development? Eventually we may want both options what should we default to or implement first? Should linux and windows implementations be separate tickets? Add Comment This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574)
Jira (BOLT-338) Local transport for orchestrator
Title: Message Title Alex Dreyer created an issue Puppet Task Runner / BOLT-338 Local transport for orchestrator Issue Type: New Feature Assignee: Unassigned Created: 2018/02/14 1:24 PM Priority: Normal Reporter: Alex Dreyer Executing tasks locally is a powerful method of extending the plan language without writing ruby. Currently bolt has to connect over a normal transport to execute local tasks. Instead bolt should have a special local transport that can be used. Users can target the local transport with the bare string "localhost" Users can target localhost with the protocol 'local'. The rest of the uri will be ignored. Implementation: Windows and linux code should be kept in separate classes with the executor deciding which version to load/use. The Inventory should be responsible for handling the host named 'localhost' and returning a host with the local transport. Questions: Should the transport copy task files before execution to make it more useful for iteration during task development? Eventually we may want both options what should we default to or implement first? Add Comment
