 |
 |
Hi Jacek, our current test tools don’t do multi-node setup, they are all running in mono-node configuration and do not define any workers. We will need Vaikunth's setup to do anything useful with CSS node definition. Cheers, Andy Becla, Jacek wrote on 2015-04-12: > Andy > > I ran integration tests using the tip of the master > and peeked inside the info stored in CSS (and didn't > find this information there). Are integration tests > using your loader? > > I looked for /NODES/ > > Jacek > > > > On 04/11/2015 04:45 AM, Salnikov, Andrei A. wrote: >> Hi Jacek, >> >> that is already implemented in current data loader when >> one does multi-node loading. As Fritz says this needs >> to be coordinated with replication system (whatever we >> are going to have) but I still believe some info needs >> to be stored persistently in central reliable location. >> >> Cheers, >> Andy >> >> Becla, Jacek wrote on 2015-04-11: >>> Andy, >>> >>> We should implement saving the information in CSS about >>> chunk locations (which chunk is loaded to which worker), >>> something like what we have in: >>> >>> https://dev.lsstcorp.org/trac/wiki/db/Qserv/CSS: >>> >>> /DBS/<dbName>/TABLES/<tableName>/CHUNKS >>> >>> This is starting to touch on data distribution... >>> >>> Are you planning to implement it as part of DM-2385? >>> >>> Without that info, checking consistency of tables >>> (DM-1898) does not make much sense. >>> >>> Thanks >>> Jacek >> >> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1