Bug 1393034

>both commands also print out "write: Broken pipe"

oops, disregard this. my netcat which was running in background was sending this to my terminal.

this turns out to be API issue:

$ curl -sku admin:changeme -H "content-type: application/json" -d '{"smart_proxy": {"name": "rplevka_cap", "url": "https://sat6.com:11018", "organization_ids": ["1"] }}' "https://sat6.com/api/v2/smart_proxies/" | jq
{
  "created_at": "2016-11-29 10:23:25 UTC",
  "updated_at": "2016-11-29 10:23:25 UTC",
  "name": "rplevka_cap",
  "id": 27,
  "url": "https://sat6.com:11018",
  "features": [
    {
      "name": "Pulp",
      "id": 2
    },
...
  ],
  "locations": [
    {
      "id": 2,
      "name": "Default Location",
      "title": "Default Location",
      "description": null
    }
  ],
  "organizations": [
    {
      "id": 1,
      "name": "Default Organization",
      "title": "Default Organization",
      "description": null
    },
    {
      "id": 27,
      "name": "ad8GIp",
      "title": "ad8GIp",
      "description": null
    },
    {
      "id": 20,
      "name": "aLdgzrSbcJJI",
      "title": "aLdgzrSbcJJI",
      "description": null
    },
...
]


The same happens via UI

Hi roman,

I think you may be doing something wrong, or may have the wrong expectations.  

When a capsule registers/is created in the web UI we need special behavior to be done when this is the 'default' or 'internal' capsule.  The way we detect that this is the internal capsule is by looking for a feature called 'pulp'.  External capsules that serve content currently have a 'pulp_node' feature.  This lets us differentiate between internal vs external.

The internal capsule is assigned to ALL orgs and locations.  In this case you are registering a smart proxy that has the 'pulp' feature which is reserved for the internal capsule.  In this case are assuming that you are registering the internal capsule and thus are associating it with all orgs and locations. 

So a couple of questions:

1) if you're trying to test the creation/registration of an external capsule, how are you installing it and why does it have the 'pulp' feature?
2) can you retest with a smart proxy that has the pulp_node feature but NOT the pulp feature.

To me this is a result of how the system behaves and is NOTABUG

> 1) if you're trying to test the creation/registration of an external
> capsule, how are you installing it and why does it have the 'pulp' feature?
> 2) can you retest with a smart proxy that has the pulp_node feature but NOT
> the pulp feature.
> 
> To me this is a result of how the system behaves and is NOTABUG

okay, that actually makes sense.
The way we tested basic capsule entity functionality (CRUD) was, that we actually set up a port forward pointing to the internal capsule (:9090). This way, we we're able to act as totally different and working capsule without a need of actually deploying one.

However, since this is just a mirror of the internal capsule, it will show the 'pulp' service and satellite thus auto-assigns such capsules to all orgs&locs.

We're going to need to deploy the real capsule after all.

Thanks for the explanation.

- I'll keep this BZ open until i do some more testing and will come back and close it as NOTABUG if it is okay.

(In reply to Justin Sherrill from comment #5)
> ...
> To me this is a result of how the system behaves and is NOTABUG

Justin, we discussed this with my colleague and  we came to a conclusion, that the bug is still valid as the system allows user to modify (even the internal) capsule in a way that it only belongs to a subset of orgs&locs. Thus we believe this should be supported also in 'create' subcommand and installer. What's more, it is a valid scenario to have an internal capsule only exposed to some orgs (not all).

What do you think?

Hey Roman, 

If you can remove any orgs or locations from the default capsule, i think that is a bug.  

Right now there are certain features that rely on the default capsule being visible (such as publishing a content view with puppet modules).  The reason for this is that we publish the modules to the local capsule and then read in all the classes to have the proper class listing in the UI.  Not to say it would be impossible to do with an external capsule, it would just require a bit more work and isn't a use case we've really considered.  Right now we are expecting the default capsule to be exposed to all organizations and haven't really done any testing without that, so i think that is not a valid scenario (although maybe could become one in the future?).

(In reply to Justin Sherrill from comment #8)
> Hey Roman, 
> 
> If you can remove any orgs or locations from the default capsule, i think
> that is a bug.  


That is definitely possible:

```
[root@mysat628 ~]# hammer -u admin -p changeme organization list
---|----------------------|----------------------|------------
ID | NAME                 | LABEL                | DESCRIPTION
---|----------------------|----------------------|------------
1  | Default Organization | Default_Organization |            
3  | foo                  | foo                  |            
---|----------------------|----------------------|------------
[root@mysat628 ~]# hammer -u admin -p changeme proxy info --id 1
Id:            1
Name:          mysat628.com
URL:           https://mysat628.com:9090
Features:      
    Pulp
    TFTP
    DNS
    DHCP
    Puppet
    Puppet CA
    Dynflow
    Discovery
    Openscap
    SSH
Locations:     
    Default Location
Organizations: 
    Default Organization
    foo
Created at:    2017/03/01 13:45:46
Updated at:    2017/03/01 13:45:47

[root@mysat628 ~]# 
[root@mysat628 ~]# 
[root@mysat628 ~]# 
[root@mysat628 ~]# hammer -u admin -p changeme proxy update --id 1 --organization-ids=1
Smart proxy updated
[root@mysat628 ~]# hammer -u admin -p changeme proxy info --id 1
Id:            1
Name:          mysat628.com
URL:           https://mysat628.com:9090
Features:      
    Pulp
    TFTP
    DNS
    DHCP
    Puppet
    Puppet CA
    Dynflow
    Discovery
    Openscap
    SSH
Locations:     
    Default Location
Organizations: 
    Default Organization
Created at:    2017/03/01 13:45:46
Updated at:    2017/03/01 13:45:47

[root@mysat628 ~]# 
[root@mysat628 ~]# 
[root@mysat628 ~]# 
[root@mysat628 ~]# hammer -u admin -p changeme proxy update --id 1 --organization-ids=""
Smart proxy updated
[root@mysat628 ~]# hammer -u admin -p changeme proxy info --id 1
Id:         1
Name:       mysat628.com
URL:        https://mysat628.com:9090
Features:   
    Pulp
    TFTP
    DNS
    DHCP
    Puppet
    Puppet CA
    Dynflow
    Discovery
    Openscap
    SSH
Locations:  
    Default Location
Created at: 2017/03/01 13:45:46
Updated at: 2017/03/01 13:45:47
```

(In reply to Justin Sherrill from comment #8)
> Right now there are certain features that rely on the default capsule being
> visible ...

hmm a quick question on this on - Is a scenario with having multiple capsules assigned to an Organization a valid one? Won't they interfere with each other?

Multiple (external) capsules assigned to 1 organization is a perfectly valid use case.  Generally the user chooses which capsule they want to use for a particular feature (such as puppet master, content source, etc..).  You can even have 1 host using two different capsules for different purposes.  

Multiple (internal/default) capsules is not a valid use case, there should only ever be 1 period.

The hammer commands here: https://bugzilla.redhat.com/show_bug.cgi?id=1393034#c9

do show a bug, so feel free to file another bz or repurpose this one.

Going ahead and closing this.  Feel free to file another bug for the ability to change the orgs/locs on the default capsule from the api/cli.

Thanks!