Confuson about which user to use in SAIO documentation

Bug #1126389 reported by Martina Kollarova
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Fix Released
Low
Kun Huang

Bug Description

The documentation http://docs.openstack.org/developer/swift/development_saio.html says:

"So, swift:swift ought to be used in every place where this manual calls for <your-user-name>:<your-group-name>."

This doesn't seem right. Isn't the swift user meant to be running the daemons? He doesn't have a home dir nor a login shell. If this was intended, I would expect that the manual would directly say "swift" instead of "<your-user-name>".

Also, it's sometimes unclear if you should be running commands as root or as a normal user. I guess there should be a note about using a normal account in the "Getting the code and setting up test environment" and "Setting up scripts for running Swift" sections.

Revision history for this message
clayg (clay-gerrard) wrote :

I'm not sure why the Fedora guide differs form the Ubuntu guide in this regard? I've apparently never looked at it too closely.

On my development saio (which happens to be ubuntu), there is no swift user or group. Swift is installed from git, and all the configuration and starting of swift services is done manually - according to the description in the rest of the guide. For my development machine, all services run as the same user I log in with (clayg as it happens) - and so that's what I put where the configs call for <your-user-name>.

If you installed the swift rpm's according to the fedora guide you may very well want the daemons to run as the swift user and artifacts to be owned by that user.

Otherwise, you may want to skip that first step:

    yum install openstack-swift openstack-swift-proxy openstack-swift-account openstack-swift-container openstack-swift-object

And just install swift from source as described later:

http://docs.openstack.org/developer/swift/development_saio.html#getting-the-code-and-setting-up-test-environment

I think it is confusing, defiantly a doc bug. Why should the Fedora instructions be so different. Maybe the original author will comment on this bug, or someone can spin up a Fedora vm and update the docs as appropriate. (You wanna do it?!)

Changed in swift:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Martina Kollarova (mkollaro) wrote :

Yes, I was wondering why am I supposed to use the rpms when I end up installing from source in the end? I think that first step shouldn't be there.

> Maybe the original author will comment on this bug, or someone can spin
> up a Fedora vm and update the docs as appropriate. (You wanna do it?!)

I can try, but I'm a complete beginner in this...

Changed in swift:
assignee: nobody → Kun Huang (academicgareth)
Revision history for this message
Kun Huang (academicgareth) wrote :

I'm working on improving details of this documents.

Changed in swift:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (master)

Reviewed: https://review.openstack.org/32241
Committed: http://github.com/openstack/swift/commit/90c422deae1b5b59102f4c616474d8bace0e2fe9
Submitter: Jenkins
Branch: master

commit 90c422deae1b5b59102f4c616474d8bace0e2fe9
Author: Kun Huang <email address hidden>
Date: Sat Jun 8 16:01:50 2013 +0800

    Improve SAIO deploy document.

    improving points:
    1. Remove yum install swift in Fedora; Use installing from source for
    both Ubuntu and Fedora.
    2. Explain you could use all users including root, your own guest. An
    d the points developer have to care.

    Change-Id: Id6d683441bd790a21734624e29eb7c98bb40de85
    Fixes: bug #1126389

Changed in swift:
status: In Progress → Fix Committed
Changed in swift:
milestone: none → 1.9.0
Thierry Carrez (ttx)
Changed in swift:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.