Open shira-lev opened 1 year ago
@shira-lev Serverless Compose was more a POC and is not planned to be evaluated in given form.
There's a chance we will revisit and implement this functionality so it works in a single process within Serverless Framework (having that this problem will not be present), but there's no ETA on that.
@medikoo can you please elaborate on that, we thought that Serverless Compose is a valid tool for deployment and not a POC stage...
@medikoo can you please elaborate on that, we thought that Serverless Compose is a valid tool for deployment and not a POC stage
@nadavbrkt this was quickly patched POC, and compose
functionality if accepted for Serverless Framework was not meant to be implemented in a way as it is currently implemented (where underlying Framework deployments are scheduled with individual Node.js processes - that's very problematic and ineffective approach)
You can use it for deployment, as far as it works for you, but please also take into account that this POC is no longer maintained in the given form
Hey everyone, since this is a public forum I feel like I need to clarify for future readers. Serverless Framework Compose was released as a stable feature of Serverless Framework. It was not released as a POC. Some more details:
serverless
CLI and its documentation: https://www.serverless.com/framework/docs/guides/composeTo clarify, I no longer work at Serverless, so if this feature is no longer supported by the company today, that is what it is. If the design choices made by our former team are invalidated as well, that is what it is. But it would be incorrect to say that it was never released as a stable feature.
@mnapoli It's mostly true. Still, to further clarify:
On the engineering side, design, where multiple Framework processes are run in the background, was since the beginning acknowledged as a dead-end route (due to its inefficiency, limitations, and other issues it comes with), not something with which this feature should be built for long-lasting evaluation and maintenance.
The agreement was that when we decide to make it a first-class Framework feature (which doesn't require a separate installation step, as it's the case currently), it'll be integrated into the Framework core and work in the realm of the single process as Framework works presently.
I'm personally a big fan of a Compose. It's a vital feature of the Framework, and I'm advocating for its real adoption into the Serverless Framework. Hopefully, we can make it part of v4 release. Still, ETA for that is unknown.
@nadavbrkt to reiterate:
Compose in the given form is a stable valid tool to use for development, but the issues that emerge in certain scenarios are not something that can be addressed easily, and there are no plans for further iterations on how it's implemented currently.
It's not a first-class Framework feature (it's not part of its core), hopefully, it'll become one day, and then it'll be a different story.
Are you certain it's a bug?
Are you using the latest version?
Is there an existing issue for this?
Issue description
Hello, Following this discussion - #172 I am using serverless compose to deploy several services. In one of my deployed services I use an internal plugin of my company that requires RawMode to be supported (the plugin is invoking some cli commands that require user input). The plugin is hooking in to the serverless
deploy
andremove
commands.When I use the plugin with regular serverless framework (not compose) it works perfectly - wait for the user input as expected. When I use it with compose it fail - saying Raw Mode is not supported.
After looking deeper in the differences between the regular serverless deployment and the serverless compose I noticed that the stream type was different, The serverless framework created a stream of type ReadStream whereas the serverless compose created a stream of type Socket. As the plugin I use required to read the stream it failed to do so with the stream of type Socket (it's not readable).
I looked for the part where the Socket stream is created and saw that it's created with a child.process spawn function (just as the plugin I use do), but the difference was that the
stdio
option was getting undefined - https://github.com/serverless/compose/blob/main/components/framework/index.js#:~:text=stdio%3A%20streamStdout%20%3F%20%27inherit%27%20%3A%20undefined%2C It got undefined because thestreamStdout
has a default false value, since thedeploy
andremove
functions did not initialize it with any other value it remained false.After adding the
streamStdout = true
to bothdeploy
andremove
functions I was able to use my plugin as expected. This is the change I have made -When invoking
exec
function fromdeploy
:await this.exec('serverless', ['deploy'], true);
And from
remove
:await this.exec('serverless', ['remove'], true);
I'd be happy to open a PR regarding this matter and add the changes as I written above. Thanks, Shira
Service configuration (serverless-compose.yml) content
Command name and used flags
serverless deploy --stage=dev
Command output