Status do SISP
-
7 de Janeiro de 2016 às 22:42A equipe investigou os problemas no ambiente do SISP e já fizemos algumas
melhorias na Task de importação dos softwares do SISP que bagunçava
algumas comunidades do ambiente do SPB. Após isso, restauramos o backup e
fizemos converge na dev outra vez e importamos novamente.
No entanto, o problema de um software de um catálogo do SPB redirecionar
para um do SISP e vice-versa continuou. Avaliando os logs e tudo mais,
identificamos que muito provavelmente o problema está somente na parte da
busca e visualização dos softwares no catálogo, pois este não está sabendo
diferenciar um software que está nos dois ambientes. Acreditamos que isso
seja algo fácil de resolver.
Segunda retomaremos os trabalhos com muito otimismo.
Att
Tallys Martins -
8 de Janeiro de 2016 às 01:33Em 7 de janeiro de 2016 20:42, Tallys Martins
escreveu:> A equipe investigou os problemas no ambiente do SISP e já fizemos algumas
> melhorias na Task de importação dos softwares do SISP que bagunçava
> algumas comunidades do ambiente do SPB. Após isso, restauramos o backup e
> fizemos converge na dev outra vez e importamos novamente.
>
> No entanto, o problema de um software de um catálogo do SPB redirecionar
> para um do SISP e vice-versa continuou. Avaliando os logs e tudo mais,
> identificamos que muito provavelmente o problema está somente na parte da
> busca e visualização dos softwares no catálogo, pois este não está sabendo
> diferenciar um software que está nos dois ambientes. Acreditamos que isso
> seja algo fácil de resolver.
>
> Segunda retomaremos os trabalhos com muito otimismo.
>Muito bom, Tallys e equipe.
Semana que vem vamos bombar com os sêniors do projeto conosco no LAPPIS ;)
--
Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br) -
8 de Janeiro de 2016 às 11:55Oi!
On 07-01-2016 19:42, Tallys Martins wrote:> No entanto, o problema de um software de um catálogo do SPB
> redirecionar para um do SISP e vice-versa continuou. Avaliando os logs
> e tudo mais, identificamos que muito provavelmente o problema está
> somente na parte da busca e visualização dos softwares no catálogo,
> pois este não está sabendo diferenciar um software que está nos dois
> ambientes. Acreditamos que isso seja algo fácil de resolver.Era mesmo um problema de como o link para a comunidade estava sendo
gerado na tela de busca. Acabei de empurrar um commit para corrigir isso :)
Abraços!
Daniela -
8 de Janeiro de 2016 às 12:18On Fri, 8 Jan 2016 08:55:29 -0300
Daniela Soares Feitosawrote: > Oi!
>
> On 07-01-2016 19:42, Tallys Martins wrote:
> > No entanto, o problema de um software de um catálogo do SPB
> > redirecionar para um do SISP e vice-versa continuou. Avaliando os logs
> > e tudo mais, identificamos que muito provavelmente o problema está
> > somente na parte da busca e visualização dos softwares no catálogo,
> > pois este não está sabendo diferenciar um software que está nos dois
> > ambientes. Acreditamos que isso seja algo fácil de resolver.
>
> Era mesmo um problema de como o link para a comunidade estava sendo
> gerado na tela de busca. Acabei de empurrar um commit para corrigir isso :)
>
> Abraços!
> DanielaValeu Daniela!
Como conversei com Tallys ontem, ainda estamos rodando a task "sisp:all" manualmente. O Tallys mencionou que precisariamos rodar mais duas tasks manualmente, portanto acredito que deveriamos incluir estas tasks nas receitas do noosfero, o que acham?
--
Athos Ribeiro
http://ccsl.ime.usp.br/
http://lappis.unb.br/ -
8 de Janeiro de 2016 às 12:41On Fri, Jan 08, 2016 at 10:18:28AM -0200, Athos Ribeiro wrote:> On Fri, 8 Jan 2016 08:55:29 -0300
> Daniela Soares Feitosawrote:
>
> > Oi!
> >
> > On 07-01-2016 19:42, Tallys Martins wrote:
> > > No entanto, o problema de um software de um catálogo do SPB
> > > redirecionar para um do SISP e vice-versa continuou. Avaliando os logs
> > > e tudo mais, identificamos que muito provavelmente o problema está
> > > somente na parte da busca e visualização dos softwares no catálogo,
> > > pois este não está sabendo diferenciar um software que está nos dois
> > > ambientes. Acreditamos que isso seja algo fácil de resolver.
> >
> > Era mesmo um problema de como o link para a comunidade estava sendo
> > gerado na tela de busca. Acabei de empurrar um commit para corrigir isso :)
> >
> > Abraços!
> > Daniela
>
> Valeu Daniela!
>
> Como conversei com Tallys ontem, ainda estamos rodando a task
> "sisp:all" manualmente. O Tallys mencionou que precisariamos rodar
> mais duas tasks manualmente, portanto acredito que deveriamos incluir
> estas tasks nas receitas do noosfero, o que acham?Assim como na migração do SPB antigo, provavelmente não faz muito
sentido, porque a gente não quer que isso rode em todo deploy.
outra coisa, o processo de "importar os dados do catálogo SISP" deveria
ser um comando só, se tem mais de um a gente tá fazendo alguma coisa
errada.
--
Antonio Terceiro
http://softwarelivre.org/terceiro -
8 de Janeiro de 2016 às 17:01Terceiro, as duas tasks mencionadas pelo Athos não possuem relação com o
sisp. A Task do sisp é uma só.
Dessas outras, uma vai pegar um artigo criado pela equipe de design no
template de software e vai copiá-lo para os outros softwares, colocando o
link dele num bloco de links. Não foi feita uma migration, pois ela pode
ser rodada outra vez caso tenha alguma alteração nesse artigo do template
(o que foi o caso quando mudou a url da página da lista de discussões que é
usada nesse artigo). E também não queremos ela executando em todo deploy,
pois é algo pontual.
A outra Task adiciona bloco de eventos e breadcrumbs aos softwares, essa
também é pontual. Então acho que não há necessidade de automatizar.
Em 8 de janeiro de 2016 10:41, Antonio Terceiroescreveu:
> On Fri, Jan 08, 2016 at 10:18:28AM -0200, Athos Ribeiro wrote:
> > On Fri, 8 Jan 2016 08:55:29 -0300
> > Daniela Soares Feitosawrote:
> >
> > > Oi!
> > >
> > > On 07-01-2016 19:42, Tallys Martins wrote:
> > > > No entanto, o problema de um software de um catálogo do SPB
> > > > redirecionar para um do SISP e vice-versa continuou. Avaliando os
> logs
> > > > e tudo mais, identificamos que muito provavelmente o problema está
> > > > somente na parte da busca e visualização dos softwares no catálogo,
> > > > pois este não está sabendo diferenciar um software que está nos dois
> > > > ambientes. Acreditamos que isso seja algo fácil de resolver.
> > >
> > > Era mesmo um problema de como o link para a comunidade estava sendo
> > > gerado na tela de busca. Acabei de empurrar um commit para corrigir
> isso :)
> > >
> > > Abraços!
> > > Daniela
> >
> > Valeu Daniela!
> >
> > Como conversei com Tallys ontem, ainda estamos rodando a task
> > "sisp:all" manualmente. O Tallys mencionou que precisariamos rodar
> > mais duas tasks manualmente, portanto acredito que deveriamos incluir
> > estas tasks nas receitas do noosfero, o que acham?
>
> Assim como na migração do SPB antigo, provavelmente não faz muito
> sentido, porque a gente não quer que isso rode em todo deploy.
>
> outra coisa, o processo de "importar os dados do catálogo SISP" deveria
> ser um comando só, se tem mais de um a gente tá fazendo alguma coisa
> errada.
>
> --
> Antonio Terceiro
>http://softwarelivre.org/terceiro
>
>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
> -
8 de Janeiro de 2016 às 17:30Tallys, essa questão de adicionar blocos vai precisar ser executada se
formos subir um ambiente do zero? Se sim precisa ser automatizado. Apenas
coisas de migração de dados acredito que nãos seja necessário automatizar,
lembrando que adicionar esses passos às receitas é uma forma de documentar
o processo de deploy, para que o mesmo seja replicável em ambientes novos.
Em 8 de janeiro de 2016 15:01, Tallys Martinsescreveu:
> Terceiro, as duas tasks mencionadas pelo Athos não possuem relação com o
> sisp. A Task do sisp é uma só.
>
> Dessas outras, uma vai pegar um artigo criado pela equipe de design no
> template de software e vai copiá-lo para os outros softwares, colocando o
> link dele num bloco de links. Não foi feita uma migration, pois ela pode
> ser rodada outra vez caso tenha alguma alteração nesse artigo do template
> (o que foi o caso quando mudou a url da página da lista de discussões que é
> usada nesse artigo). E também não queremos ela executando em todo deploy,
> pois é algo pontual.
>
> A outra Task adiciona bloco de eventos e breadcrumbs aos softwares, essa
> também é pontual. Então acho que não há necessidade de automatizar.
>
> Em 8 de janeiro de 2016 10:41, Antonio Terceiro <
> terceiro@softwarelivre.org> escreveu:
>
>> On Fri, Jan 08, 2016 at 10:18:28AM -0200, Athos Ribeiro wrote:
>> > On Fri, 8 Jan 2016 08:55:29 -0300
>> > Daniela Soares Feitosawrote:
>> >
>> > > Oi!
>> > >
>> > > On 07-01-2016 19:42, Tallys Martins wrote:
>> > > > No entanto, o problema de um software de um catálogo do SPB
>> > > > redirecionar para um do SISP e vice-versa continuou. Avaliando os
>> logs
>> > > > e tudo mais, identificamos que muito provavelmente o problema está
>> > > > somente na parte da busca e visualização dos softwares no catálogo,
>> > > > pois este não está sabendo diferenciar um software que está nos dois
>> > > > ambientes. Acreditamos que isso seja algo fácil de resolver.
>> > >
>> > > Era mesmo um problema de como o link para a comunidade estava sendo
>> > > gerado na tela de busca. Acabei de empurrar um commit para corrigir
>> isso :)
>> > >
>> > > Abraços!
>> > > Daniela
>> >
>> > Valeu Daniela!
>> >
>> > Como conversei com Tallys ontem, ainda estamos rodando a task
>> > "sisp:all" manualmente. O Tallys mencionou que precisariamos rodar
>> > mais duas tasks manualmente, portanto acredito que deveriamos incluir
>> > estas tasks nas receitas do noosfero, o que acham?
>>
>> Assim como na migração do SPB antigo, provavelmente não faz muito
>> sentido, porque a gente não quer que isso rode em todo deploy.
>>
>> outra coisa, o processo de "importar os dados do catálogo SISP" deveria
>> ser um comando só, se tem mais de um a gente tá fazendo alguma coisa
>> errada.
>>
>> --
>> Antonio Terceiro
>>http://softwarelivre.org/terceiro
>>
>>
>>
>> _______________________________________________
>> spb-dev mailing list
>> spb-dev@listas.softwarepublico.gov.br
>>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>>
>>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>
--Lucas Kanashiro -
8 de Janeiro de 2016 às 17:41Kanashiro, a questão é a seguinte: se a pessoa quiser criar um ambiente do
zero e ter o visual igual ao do SPB ela somente vai ter que criar o
template IGUAL ao do SPB, adicionando os mesmos blocos e isso é feito na
mão. Essas Tasks são criadas pois os softwares não pegam 100% das
características dos templates depois que já foram criados. Por exemplo, a
gente vai adicionar um bloco no template, mas os softwares que seguem esse
template não vão ganhar o bloco, somente os novos que forem criados depois.
Esse é o motivo de criarmos as Tasks, para repor nos antigos, pois ainda
não existe a funcionalidade de resetar para seguir o template alterado.
Caso a pessoa vá usar um backup do SPB, já vai vir com tudo pronto, não
precisando rodar nenhuma task.AttEm 8 de janeiro de 2016 15:30, Lucas Kanashiroescreveu:
> Tallys, essa questão de adicionar blocos vai precisar ser executada se
> formos subir um ambiente do zero? Se sim precisa ser automatizado. Apenas
> coisas de migração de dados acredito que nãos seja necessário automatizar,
> lembrando que adicionar esses passos às receitas é uma forma de documentar
> o processo de deploy, para que o mesmo seja replicável em ambientes novos.
>
> Em 8 de janeiro de 2016 15:01, Tallys Martins
> escreveu:
>
>> Terceiro, as duas tasks mencionadas pelo Athos não possuem relação com o
>> sisp. A Task do sisp é uma só.
>>
>> Dessas outras, uma vai pegar um artigo criado pela equipe de design no
>> template de software e vai copiá-lo para os outros softwares, colocando o
>> link dele num bloco de links. Não foi feita uma migration, pois ela pode
>> ser rodada outra vez caso tenha alguma alteração nesse artigo do template
>> (o que foi o caso quando mudou a url da página da lista de discussões que é
>> usada nesse artigo). E também não queremos ela executando em todo deploy,
>> pois é algo pontual.
>>
>> A outra Task adiciona bloco de eventos e breadcrumbs aos softwares, essa
>> também é pontual. Então acho que não há necessidade de automatizar.
>>
>> Em 8 de janeiro de 2016 10:41, Antonio Terceiro <
>> terceiro@softwarelivre.org> escreveu:
>>
>>> On Fri, Jan 08, 2016 at 10:18:28AM -0200, Athos Ribeiro wrote:
>>> > On Fri, 8 Jan 2016 08:55:29 -0300
>>> > Daniela Soares Feitosawrote:
>>> >
>>> > > Oi!
>>> > >
>>> > > On 07-01-2016 19:42, Tallys Martins wrote:
>>> > > > No entanto, o problema de um software de um catálogo do SPB
>>> > > > redirecionar para um do SISP e vice-versa continuou. Avaliando os
>>> logs
>>> > > > e tudo mais, identificamos que muito provavelmente o problema está
>>> > > > somente na parte da busca e visualização dos softwares no catálogo,
>>> > > > pois este não está sabendo diferenciar um software que está nos
>>> dois
>>> > > > ambientes. Acreditamos que isso seja algo fácil de resolver.
>>> > >
>>> > > Era mesmo um problema de como o link para a comunidade estava sendo
>>> > > gerado na tela de busca. Acabei de empurrar um commit para corrigir
>>> isso :)
>>> > >
>>> > > Abraços!
>>> > > Daniela
>>> >
>>> > Valeu Daniela!
>>> >
>>> > Como conversei com Tallys ontem, ainda estamos rodando a task
>>> > "sisp:all" manualmente. O Tallys mencionou que precisariamos rodar
>>> > mais duas tasks manualmente, portanto acredito que deveriamos incluir
>>> > estas tasks nas receitas do noosfero, o que acham?
>>>
>>> Assim como na migração do SPB antigo, provavelmente não faz muito
>>> sentido, porque a gente não quer que isso rode em todo deploy.
>>>
>>> outra coisa, o processo de "importar os dados do catálogo SISP" deveria
>>> ser um comando só, se tem mais de um a gente tá fazendo alguma coisa
>>> errada.
>>>
>>> --
>>> Antonio Terceiro
>>>http://softwarelivre.org/terceiro
>>>
>>>
>>>
>>> _______________________________________________
>>> spb-dev mailing list
>>> spb-dev@listas.softwarepublico.gov.br
>>>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>>>
>>>
>>
>> _______________________________________________
>> spb-dev mailing list
>> spb-dev@listas.softwarepublico.gov.br
>>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>>
>>
>
>
> --
> Lucas Kanashiro
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>
Ordenar por:
Relacionado:
- spb-dev Status Noosfero
Estatísticas:
-
iniciada em
8 anos, 3 meses atrás
-
vizualizada
1203 vezes
-
respondida
8 vezes
-
votada
0 vezes