Hola,
El tema de las imágenes ARI lo empezaré a mirar mañana para resolverlo.
Y el tema de la paginación que hace por defecto el API de Openstack también
lo tenemos que ir resolviendo, aunque a priori no sé decir cuando lo tendré
resuelto. Os iré avisando.
Saludos,
Javi.
2013/8/19 José Ignacio Carretero <e.cloud10 at tid.es>
>
>
>
>
> El 19/08/13 13:46, Alvaro Arranz escribió:
>
> Hola Henar,
>
> tenemos varios problemas con el portal de cloud (nosotros usamos
> http://130.206.80.61, no sé si tiene DNS):
>
> - no veo ninguna imagen de CentOS o de Debian (salvo:
> centos64-kernel-2.6.32-279.11.1 y centos64-ramdisk-2.6.32-279.11.1 que
> supongo que no contienen sistemas funcionales). La quería usar para crear
> la instancia de wirecloud para el OIL. De principio estaría bien hacer una
> copia de la VM de la máquina que usamos en el testbed, pero dado que está
> máquina la habéis creado vosotros no aparece en nuestro panel y por lo
> tanto nosotros no podemos copiarla.
>
> Esto es un problema que os comenté hace algunos días (Lo de la Centos)
> y es que en el portal están apareciendo cosas que no tienen que aparecer
> (lo hablé con J. Cerviño) ---
>
> 1. No se deben mostrar (más que al administrador) imágenes de tipo ARI y
> AKI (y en este caso se están mostrando)
> 2. No veo como continuar el listado sacando más imágenes, es decir, se
> muestran las 25 primeras imágenes, pero el resto no se muestran.
>
>
>
> - intenté hacer un snapshot de la máquina del store y se ha quedado
> pendiente para siempre. Esta si me gustaría copiarla, porque Fran (que se
> encarga del store) está ahora mismo de vacaciones y hay algún detalle de la
> configuración que no me se del todo.
>
> Tuvimos un problema que espero poco a poco ir resolviendo las
> consecuencias que ha tenido ---
>
>
> - hace unas semanas reinicie una de las máquinas (historymod) y aunque
> ahora está funcionando se ha quedado en estado: HARD_REBOOT y en la
> tarea: rebooting_hard.
>
> Por otro lado, y aprovechando este correo. Hemos subido las recetas chef
> al svn, pero no salen listadas en http://130.206.80.113:4040/cookbooks,
> las hemos probado en una máquina virtual de chef-solo y de principio
> estaban funcionando. Puede que hayamos subido algo mal al svn o que hayamos
> metido mal los datos en los ficheros metadata.rb ¿Nos podéis echar una mano?
>
> Un saludo.
>
>
>
> 2013/8/7 HENAR MUÑOZ FRUTOS <henar at tid.es>
>
>> Buenos días
>>
>>
>>
>> Me podéis pasar las IPs y los nombre de dominio de los portales, tanto en
>> la parte del testbed como del lab (para OIL y campus party)?. Además
>> comentarme si necesitáis algún nombre de dominio nuevo y me encargué de
>> meterlo en el DNS.
>>
>>
>>
>> Muchas gracias,
>>
>> Saludos,
>>
>> Henar
>>
>>
>>
>>
>>
>>
>>
>> *De:* fiware-portals-bounces at lists.fi-ware.eu [mailto:
>> fiware-portals-bounces at lists.fi-ware.eu] *En nombre de *Francisco de la
>> Vega
>> *Enviado el:* miércoles, 07 de agosto de 2013 9:14
>> *Para:* Antonio Tapiador del Dujo
>> *CC:* fiware-portals at lists.fi-ware.eu
>> *Asunto:* Re: [Fiware-portals] API de notificaciones
>>
>>
>>
>> Hola,
>>
>> ¿Cual es el endpoint donde tienen que llegar las notificaciones de compra
>> al idM?
>>
>> Saludos,
>>
>> Francisco
>>
>>
>>
>> El 6 de agosto de 2013 17:17, Antonio Tapiador del Dujo <
>> atapiador at dit.upm.es> escribió:
>>
>> Hecho!
>>
>> El 06/08/13 16:56, Francisco de la Vega escribió:
>>
>> Hola,
>>
>> Para el desarrollo estoy utilizando una applicación de testing con
>> client_id 16 y necesitaría que pudiera acceder a estas APIs.
>>
>> Saludos,
>>
>> Francisco
>>
>>
>>
>> El 6 de agosto de 2013 16:04, Antonio Tapiador del Dujo <
>> atapiador at dit.upm.es> escribió:
>>
>> Hola Francisco,
>>
>> ya tienes el API lista en producción. Respecto al token, debería valer
>> cualquier formato descrito en el RFC 6750
>>
>> Solo la aplicación con id 18 debería tener permiso para atacar este punto
>> del API. Si tienes otras aplicaciones o pruebas, dime y las registro.
>> Cualquier duda o error, no dudes en consultarme
>>
>> Un saludo.
>>
>>
>> El 05/08/13 18:16, Francisco de la Vega escribió:
>>
>> Hola,
>>
>> Las notificaciones quedarían como:
>>
>> {
>> "offering": {
>> "organization": "owner_organization",
>> "name": "offering_name",
>> "version": "offering_version"
>> },
>> "reference": "referencia_de_compra",
>> "customer": "actor_id",
>>
>> "applications": [{"id": 16,
>> "name": "app"},
>> {"id":20,
>> "name":"app2"}]
>>
>> }
>>
>> El campo customer contendria el actor_id tanto de un usuario como de una
>> organización.
>>
>> Por otra parte ¿como quieres el token?, ahora mismo lo paso en la
>> cabecera Authentication: Bearer .token.
>>
>> Saludos,
>>
>> Francisco
>>
>>
>>
>> El 5 de agosto de 2013 17:46, Antonio Tapiador del Dujo <
>> atapiador at dit.upm.es> escribió:
>>
>> Hola Fancisco, también tienes lista el API de aplicaciones:
>>
>> https://github.com/ging/fi-ware-idm/wiki/API#applications
>>
>> El endpoint de compras en el IdM puede ser /purchases, ¿cómo queda el
>> JSON al final?
>>
>> Un saludo.
>>
>>
>> El 02/08/13 14:34, Antonio Tapiador del Dujo escribió:
>>
>> Estupendo, ya lo tienes tanto en el wiki como desplegado en producción
>>
>> https://github.com/ging/fi-ware-idm/wiki/Using-the-deployed-instance
>>
>> Por cierto, he aprovechado para cambiar el parámetro organization.name a
>> organization.displayName siguiendo el esquema de grupos de SCIM que se ha
>> acordado como API en el paquete de seguridad. Aún tengo la tarea pendiente
>> de revisarlo en profundidad, por lo que es posible que haya algún que otro
>> pequeño cambio. Os aviso.
>>
>> Un saludo.
>>
>> El 02/08/13 13:15, Francisco de la Vega escribió:
>>
>> OK, entonces creo que estaría bien pasar el actor_id como customer, de
>> hecho me vendría bien para gestionar otras cosas de los usuarios y
>> organizaciones en el Store.
>>
>>
>>
>> El 2 de agosto de 2013 13:10, Antonio Tapiador del Dujo <
>> atapiador at dit.upm.es> escribió:
>>
>> Como veas, cambiar el API me supone escribir una línea más de código, así
>> que no es mucho problema. Lo que quede mejor.
>>
>>
>> El 02/08/13 13:09, Francisco de la Vega escribió:
>>
>> Creo que lo mas sencillo sería incluir un tipo (organización o usuario)
>> e incluir su id. Lo del actor_id estaría bien pero te forzaría a cambiar la
>> API para incluir ese valor en la respuesta.
>>
>>
>>
>> El 2 de agosto de 2013 13:03, Antonio Tapiador del Dujo <
>> atapiador at dit.upm.es> escribió:
>>
>> En el IdM el nombre de la organización no es único. Existen nicknames
>> tanto para organizaciones como usuarios que son únicos pero no inmutables,
>> es decir, tanto usuarios como organizaciones los pueden cambiar, aunque
>> deben poner uno que no esté cogido. Lo que es único e inmutable son los
>> ids, tanto por usuario como organización.
>>
>> Los ids se pueden repetir entre distintos modelos. Es decir, hay
>> organizacion 1 y usuario 1. Existe otro id en el idm, el id de actor, que
>> sí es único para usuarios, organizaciones y aplicaciones. Es decir, si
>> existe usuario con actor_id == 1 no puede existir organizacion con actor_id
>> == 1.
>>
>> Usando nicknames ahora mismo podría existir condiciones de carrera, es
>> decir, un usuario carga la página de una organización en la store, la
>> organización cambia su nickname y posteriormente se realiza la compra.
>>
>> Yo me quedaría más tranquilo si incluís un id por cliente, tal como
>> 'organization-1' usando los ids de organizacion, o directamente el id de
>> actor. ¿Qué te parece?
>>
>>
>> El 02/08/13 12:52, Francisco de la Vega escribió:
>>
>> Creo que en el caso del idM lo mejor es tener una URL única a la que
>> mandar las peticiones, por otra parte el customer ahora mismo contiene el
>> nickname del usuario o el nombre de la organización dependiendo de como se
>> haga la compra (En el Store el nombre de una organización es único), si el
>> nombre de las organizaciones no es único en el idM podría incluir un campo
>> más con el identificador de la organización (estoy suponiendo que se puede
>> identificar un usuario por su nickname).
>>
>> Saludos
>>
>>
>>
>> El 2 de agosto de 2013 12:40, Antonio Tapiador del Dujo <
>> atapiador at dit.upm.es> escribió:
>>
>> Estupendo Francisco, un par de dudas:
>>
>> * ¿Manejamos la misma URL en el IdM para cada oferta, o se necesita
>> registrar una nueva URL por oferta?
>> * ¿customer es el nombre de la organización o usuario cliente? Este
>> nombre puede no ser único o cambiar ¿Se podría pasar el id y/o tipo?
>>
>> El 02/08/13 10:41, Francisco de la Vega escribió:
>>
>>
>>
>> Hola,
>>
>> Con respecto a la API de notificaciones, el Store manda una petición POST
>> a la URL registrada al crear la oferta con un content type application/json
>> y con el cuerpo:
>>
>> {
>> "offering": {
>> "organization": "owner_organization",
>> "name": "offering_name",
>> "version": "offering_version"
>> },
>> "reference": "referencia_de_compra",
>> "customer": "usuario_u_organización_cliente"
>> }
>>
>> Entiendo que para la integración con el idM lo único que haría falta
>> seria incluir un un campo conteniendo las aplicaciones compradas, algo como:
>>
>> POST
>> Content-Type: application/json
>>
>> {
>> "offering": {
>> "organization": "owner_organization",
>> "name": "offering_name",
>> "version": "offering_version"
>> },
>> "reference": "referencia_de_compra",
>> "customer": "usuario_u_organización_cliente",
>> "applications": [{"id": 16,
>> "name": "app"},
>> {"id":20,
>> "name":"app2"}]
>> }
>>
>> Saludos,
>> Francisco
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Fiware-portals mailing list
>>
>> Fiware-portals at lists.fi-ware.eu
>>
>> https://lists.fi-ware.eu/listinfo/fiware-portals
>>
>>
>>
>>
>> _______________________________________________
>> Fiware-portals mailing list
>> Fiware-portals at lists.fi-ware.eu
>> https://lists.fi-ware.eu/listinfo/fiware-portals
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>> nuestra política de envío y recepción de correo electrónico en el enlace
>> situado más abajo.
>> This message is intended exclusively for its addressee. We only send and
>> receive email on the basis of the terms set out at:
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>
>> _______________________________________________
>> Fiware-portals mailing list
>> Fiware-portals at lists.fi-ware.eu
>> https://lists.fi-ware.eu/listinfo/fiware-portals
>>
>>
>
>
> ------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
> _______________________________________________
> Fiware-portals mailing list
> Fiware-portals at lists.fi-ware.eu
> https://lists.fi-ware.eu/listinfo/fiware-portals
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-portals/attachments/20130819/27f3d24a/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy