Some proposed changes to Manual Import functionality

Simeon Pinder spinder at redhat.com
Thu Apr 25 15:02:49 UTC 2013





----- Original Message -----
> From: "Alan Santos" <asantos at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Thursday, April 25, 2013 9:03:46 AM
> Subject: Re: Some proposed changes to Manual Import functionality
> 
> 
> On Apr 24, 2013, at 11:04 PM, Simeon Pinder <spinder at redhat.com> wrote:
> 
> > 
> > ----- Original Message -----
> >> From: "Alan Santos" <asantos at redhat.com>
> >> To: rhq-devel at lists.fedorahosted.org
> >> Sent: Wednesday, April 24, 2013 8:15:27 PM
> >> Subject: Re: Some proposed changes to Manual Import functionality
> >> 
> >> 
> >> I'm not sure I understand the details, but is there a reason you can't
> >> just
> >> move the existing resource out of the discovery queue and do what the user
> >> wants?
> > We don't really have a way to remove them from the discovery queue that I'm
> > aware of(short of inventory then explicit uninventory). Even if you were
> > able to they would just be added again with the next discovery pass as is
> > the purpose of auto-discovery.  Again, this is an unlikely case although
> > possible.
> 
> 
> Please help me understand why that is the case.  If I read the original email
> correctly - Tomcat  was auto-discovered and put into the discovery queue. If
> that resource was moved out of the discovery queue and into inventory as a
> result of the manual import why would it be added again with the next
> discovery pass?
No. I guess I misunderstood your earlier response.  If we did move the resource into the inventory
by COMMITTING it then it would not show back up the discovery pass.  What I meant to communicate
is that there is not clean way to clear out the autodiscovery queue without going through COMMITT.

> 
> 
> > 
> > 'Manual Import' is meant to bail the user out when auto-discovery is not
> > working or the resource is not online for auto-discovery.  The proposed
> > changes is about making it harder for the customer to use 'Manual Import'
> > to instead update existing resources in ways that it was not intended.
> > For example, we never added enough logic to define what would happen
> > when the configuration passed in instead mapped to resources in IGNORED or
> > UNINVENTORIED state.  Meaning that, if we fixed the logic to actually
> > allow the customer to 'do what he wants' that he'd then be able to modify
> > ignored resources via 'Manual Import'.  If Resource update is their actual
> > intent they should use the supported/ Resource apis/workflows.
> > 
> 
> 
> 'making it harder for the customer'. I can't let that pass by. We should be
> figuring out how to accomplish what the user is trying to do.  I don't know
> enough about the implementation details to comment on Lukas' suggestion but
> it sounds reasonable as does the issue he points out.
I guess I walked right into that one.  What I meant to say is that there are correct usage patterns
for our features.  Using Manual Import as a backdoor to update existing resources is not the intent
of Manual Import.  So by clarifying the workflow here on the server side and in the PC we would be 'making 
it harder for the customer to use our apis/ui in the wrong way. 

Fundamentally I think that Manual Import should try to stay in the import only business. 

> 
> 
> 
> 
> 
> 
> >> 
> >> 
> >> 
> >> On Apr 24, 2013, at 6:24 PM, "Larry O'Leary" <loleary at redhat.com> wrote:
> >> 
> >>> On Wed, 2013-04-24 at 14:59 -0400, Simeon Pinder wrote:
> >>>> Hi All,
> >>>> 
> >>>> After discussions with Jay, I wanted to describe some changes that I
> >>>> think
> >>>> we should make in support of 'Manual Import' functionality in the plugin
> >>>> container and potentially on the server side.
> >>>> 
> >>>> The issue:
> >>>> With BZ 883825 we stumbled into odd behavior while trying to test out
> >>>> 'Manual Import' of Tomcat instances. What wasn't immediately apparent
> >>>> was
> >>>> that those same Tomcat instances were already silently indexed by RHQ in
> >>>> the 'Discovery Queue'.  So that while attempting to 'Manual Import'
> >>>> these
> >>>> new instances with a new plugin configuration, the plugin container
> >>>> would
> >>>> take the information from the 'new' import and detect that we'd already
> >>>> had that in inventory(the auto-discovered version) and use the invalid
> >>>> configuration from that version. The result was that a user submitting a
> >>>> Manual Import with valid credentials, was getting rejected because RHQ
> >>>> was silently swapping in the wrong config with no credentials. While the
> >>>> situation just described is ugly, the wider issue is that it occurred
> >>>> because we were never clear about what should happen when one tries to
> >>>> 'Manual Import' a new resource resulting in a resource key that matches
> >>>> an existing resource.  Essentially such a behavior, if allowed, would
> >>>> result in a Resource configuration/status update which was not the
> >>>> original point.
> >>>> 
> >>>> To summarize, RHQ/JON does not do enough to detect and deter when
> >>>> 'Manual
> >>>> Import' is being used to inadvertently update the state of a Resource
> >>>> already indexed by RHQ.  Current suggestions are to:
> >>>> 
> >>>> i)Update the RHQ code to better detect and prevent such behavior with
> >>>> appropriate error messages
> >>>> - modify InventoryManager to error out when 'Manual Import' is called
> >>>> and
> >>>> an existing RHQ resource is already indexed.  The new logic should
> >>>> handle Resources in all InventoryStatus.* states better since changes to
> >>>> existing Resources should only be handled via our existing Resource
> >>>> update mechanism.  This means better agent side and server side logs
> >>>> messages when this situation is attempted in the future.  I'm also
> >>>> looking into throwing better UI errors after "Manual Import" attempts.
> >>>> Right now we only really support Plugin Configuration exceptions(bad
> >>>> creds) or Plugin Container exceptions of which this doesn't fit in
> >>>> either category well.
> >>>> 
> >>>> ii) update released/docs/support information to better describe this
> >>>> situation and workaround
> >>>> - this just means documenting this behavior and how to avoid getting
> >>>> into
> >>>> this state.  An administrator attempting to inventory resources could
> >>>> get
> >>>> into this state and it's confusing to debug/detect if auto discovery is
> >>>> doing it's job well.
> >>>> 
> >>>> iii)clarify the javadoc on the remote api documentation so that plugin
> >>>> developers know to not attempt to handle such unintentional updates.
> >>>> - Trying to support 'Manual Import', without filtering out existing
> >>>> Resources that match the same identity, is a subtle point that we
> >>>> haven't
> >>>> gotten right in the past.  The DiscoveryBossRemote public api javadoc
> >>>> implies that we will handle cases where 'Manual Import' specifies a
> >>>> plugin config that maps to an existing resource.  We need to update this
> >>>> api description here to be clearer about which situations should not be
> >>>> handled by 'Manual Import'.
> >>>> 
> >>>> This last point is tricky because there's no simple way to tell a plugin
> >>>> developers how to detect if the plugin configuration will map to an
> >>>> existing Resource already.  There is perhaps a CLI query that they can
> >>>> put together but it's not a great solution.  Logging error messages to
> >>>> the server and agent logs also isn't a great solution here from a CLI
> >>>> users standpoint.
> >>>> 
> >>>> I think we should actively discourage this usage of 'Manual Import' that
> >>>> can overlap with Resource update. Are there any other opinions here?
> >>>> 
> >>>> -Simeon
> >>> 
> >>> Perhaps manually added resources get a special key? Obviously this would
> >>> still require work/understanding from the plug-in developer to ensure
> >>> that they support manual add and that it is done in a way makes the
> >>> special key meaningful. It would be nice if we could make this happen at
> >>> the pc level.
> >>> 
> >>> Outside of that, I would think that i) above is really the only option.
> >>> If we don't allow duplicate resources (one from discovery and one from
> >>> manual add) then we need to tell the user that the add failed due to a
> >>> resource with the same key already existing. I am not really sure what
> >>> should happen though when a manually added resource makes it into
> >>> inventory and then discovery discovers a new one with the same key
> >>> (server scan ran and discovered resource, and then user uninventoried it
> >>> and manually added before another discovery ran).
> >>> 
> >>> --
> >>> Larry O'Leary
> >>> https://plus.google.com/u/0/112645929986009801513
> >>> 
> >>> _______________________________________________
> >>> rhq-devel mailing list
> >>> rhq-devel at lists.fedorahosted.org
> >>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >> 
> >> _______________________________________________
> >> rhq-devel mailing list
> >> rhq-devel at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >> 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list