Skip to content
This repository has been archived by the owner on Oct 10, 2020. It is now read-only.

atomic stop errors out because opt* args are not there for stop #137

Closed
dustymabe opened this issue Aug 28, 2015 · 7 comments
Closed

atomic stop errors out because opt* args are not there for stop #137

dustymabe opened this issue Aug 28, 2015 · 7 comments

Comments

@dustymabe
Copy link
Contributor

In the cmd_env(self) function the call to self.args.opt1 gives an error because stop doesn't have an opt1 arg.

[root@f22 foo]$ atomic  stop delloapache                                                                                                                                                                                                    
Traceback (most recent call last):
  File "/usr/bin/atomic", line 306, in <module>
    sys.exit(args.func())
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 401, in stop
    self.display(cmd)
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 759, in display
    "/usr/bin/echo \"" + cmd + "\"", env=self.cmd_env, shell=True)
  File "/usr/lib/python2.7/site-packages/Atomic/atomic.py", line 472, in cmd_env
    if self.args.opt1:
AttributeError: 'Namespace' object has no attribute 'opt1'
@dustymabe dustymabe changed the title atomicapp can't cp files out - fedora docker-1.7.1-7.gitd5a81b3.fc22.x86_64 atomic stop errors out because opt* args are not there for stop Aug 28, 2015
rhatdan added a commit that referenced this issue Aug 30, 2015
Fix issue with commands that don't have opt* args. Closes #137
@praiskup
Copy link

Shouldn't be the 'optX' rather removed completely? The major problem is
that the --optX has no defined semantics (user -- while running some atomic
command -- has no idea what are the effects of that --optX option). Because we
can pass arbitrary environment variable down to 'docker' now, we could
probably use something like DOCKER_CMD_OPTS instead of
$OPT2.

@rhatdan
Copy link
Member

rhatdan commented Sep 23, 2015

Yes makes sense to me.

@rhatdan
Copy link
Member

rhatdan commented Sep 23, 2015

@bexelbie @baude @scollier @cgwalters WDYT?

Does removing of this break anything? If a user used $OPT1 in atomic

They would just need to do.

OPT1="--debug" atomic install foobar

Rather then

atomic install --opt1="--debug" foobar

@goern
Copy link
Contributor

goern commented Sep 24, 2015

@sub-mod this question is also for you...

@rhatdan
Copy link
Member

rhatdan commented Sep 24, 2015

I think I can leave the commands in atomic, but just don't document them

@sub-mod
Copy link
Contributor

sub-mod commented Sep 24, 2015

I unfortunately need optX to be present in atomic and in atomicapp LABELs to continue supporting deployment of nulecule apps via cockpit.

@rhatdan
Copy link
Member

rhatdan commented Sep 24, 2015

THe current patch will still support --opt1 but it is no longer documented. Preferred method would be to execute

OPT1="--option" atomic run foobar

But

atomic --opt1="--option" run foobar

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants