Hi Petr,
On Thu, Jun 14, 2007 at 10:16:58AM +0400, Peter Grigoriev wrote:
> >> The main thing was to write a stand-alone package performing the
> >> ldap operations and call it from workflow actions.
> >> This way all main ldap operations can be tested automatically.
> > Sounds good. But what LDAP server do you want to test it against? I
> > believe it is possible to set up a test server using Net::LDAP::Server,
> > but it seems like it involves a good amount of work ...
> I am using OpenLDAP as described in the draft.
Hmmm, but that would introduce one more dependency on automated testing:
an installed and configured OpenLDAP server. Have you looked into
using Net::LDAP::Server yet?
> > This should be combined with a check whether the child fails (see SCEP
> > workflow). Still, this might lead to an infinitely looping workflow
> > if the child does not end up in state 'SUCCESS' or 'FAILURE' for some
> > reason ...
> Yes, I tried that approach but looping happens time by time. May be it is
So what state is the LDAP publication workflow in if looping occurs?
It has to be something else then 'SUCCESS' or 'FAILURE', right?
> worth to put ldap-publishing workflow steps inside the certificate_issue
> workflow. But the CSR workflow is waiting for the certificate_isuue
Sounds like a reasonable idea for now. Of course it makes the CSR
workflow more complex, but it is the easiest way for now.
> in the same way the certificate issue is waiting for ldap-public.
The difference is that the cert request workflow is designed not to
care whether cert issuance finishes after waiting for it or later, it
can update its state once the user views the workflow. This has no
parallel in the cert issuance - ldap publication connection.
> "You can also have multiple return states for a single action. The one
> chosen by the workflow system will depend on what the action returns. For
> instance we might have something like:
> <state name="create user">
> <action name="create">
> <resulting_state return="admin" state="Assign as Admin" />
> <resulting_state return="helpdesk" state="Assign as Helpdesk" />
> <resulting_state return="*" state="Assign as Luser" />
> </action>
> </state>"
Looks more complicated and harder to understand in the configuration
than just actions and conditions. I'd rather fix the original Workflow
problem then using this approach.
> >As for your other problems mentioned in your document, about 1) and 2):
> > are you sure you have a recent Workflow.pm? I believe I solved these
> > exact problems in 0.25/0.26 ... If so, can you please set the Workflow
> > log level to DEBUG and send me a copy of your openxpki.log so that I can
> > try and debug it?
> Yes, I have the recent Workflow that is the problem and that is why I
> decided
> not to use looping for the time being.
> As far as I remember 0.25/0.26 problem was that the condition did not
> checked
> again in the loop and the result of the previous check was used instead.
Right, that was fixed in 0.26, cached condition results are always
deleted once we move on to a different state now.
> Before 0.26 infinity looping happened ALWAYS.
> After 0.26 it happens TIME by TIME.
Weird ...
> I'll try to reproduce it and catch the log messages.
That would be good. Maybe you can try writing test workflows that do
nothing but sleeping to reproduce it? In this way, we could have an
automated test for Workflow.pm and see when the problem goes away ...
> P.S. Sorry for mixing things up and sending mail to svn instead of devel.
Never mind ...
Best regards,
Alex
--
Dipl.-Math. Alexander Klink | IT-Security Engineer
[EMAIL PROTECTED] | working @ urn:oid:1.3.6.1.4.1.11417
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
OpenXPKI-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-devel
