Re: [openstack-dev] [legal-discuss] [all][tc][kolla]is it OK to modify python code in OpenStack project?

[Jeffrey Zhang]

not simple override the _read() method. I also copied some code from
ConfigParser.py(more than 80%, i think). is that OK?

is there any difference between override method and copy codes?

On Tue, Dec 27, 2016 at 3:12 AM, Monty Taylor  wrote:

> On 12/26/2016 07:27 AM, Davanum Srinivas wrote:
> > PSF is ok per (https://governance.openstack.org/tc/reference/licensing.
> html)
> > Though the overriding the _read() seems like something that could
> > break easily
>
> Yah - you can't relicense it - but you can include it with the PSF
> license. It might be worth adding a PSF license header to that file and
> a note that the code is copied from [0]
>
> That said - I agree with dims, overriding the _read() method like that
> seems prone to sadness.
>
> > On Mon, Dec 26, 2016 at 12:13 PM, Michał Jastrzębski 
> wrote:
> >> Added all and tc tags, as it might affect everyone really.
> >>
> >> On 25 December 2016 at 23:04, Jeffrey Zhang 
> wrote:
> >>> Recently, Kolla project has requirement to modify[1] the python's
> >>> ConfigParser.py code[0].
> >>>
> >>> Python is using PSF license[3], which is GPL compatible. But OpenStack
> >>> is using Apache License.
> >>>
> >>> Here is the diff view[2].
> >>>
> >>> I want to make sure: is it OK to re-license ConfigParser.py? If not,
> what
> >>> the solution?
> >>>
> >>> [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py
> >>> [1] https://review.openstack.org/412101
> >>> [2]
> >>> https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da3
> 71/revisions?diff=split
> >>> [3] https://docs.python.org/3/license.html
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Jeffrey Zhang
> >>> Blog: http://xcodest.me
> >>>
> >>> ___
> >>> legal-discuss mailing list
> >>> legal-disc...@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
> >>>
> >>
> >> ___
> >> legal-discuss mailing list
> >> legal-disc...@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
> >
> >
> >
>
>
> ___
> legal-discuss mailing list
> legal-disc...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [trove] A question for the user survey

[Amrith Kumar]

We have the opportunity to ask one question on the upcoming user survey and
we get to decide the audience to which we serve the question.

 

Your options (for audience target) are: USING, TESTING, or INTERESTED in
Trove

 

The question can take one of several forms; multiple choice (select one or
more), or short answer.

 

Please send suggestions before Wednesday so I can respond to the team
assembling the survey in sufficient time.

 

Thanks,

 

-amrith

 

--

Amrith Kumar

  amr...@tesora.com

+1-978-563-9590

GPG: 0x5e48849a9d21a29b

 



smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Feedback for upcoming user survey questionnaire

[Jay Pipes]

On 12/26/2016 06:08 PM, Matt Riedemann wrote:

We have the opportunity to again [1] ask a question in the upcoming user
survey which will be conducted in February. We can ask one question and
have it directed to either *users* of Nova, people *testing* nova, or
people *interested* in using/adopting nova. Given the existing adoption
of Nova in OpenStack deployments (98% as of October 2016) I think that
sliding scale really only makes sense to direct a question at existing
users of the project. It's also suggested that for projects with over
50% adoption to make the question quantitative rather than qualitative.

We have until January 9th to submit a question. If you have any
quantitative questions about Nova to users, please reply to this thread
before then.

Personally I tend to be interested in feedback on recent development, so
I'd like to ask questions about cells v2 or the placement API, i.e. they
were optional in Newton but how many deployments that have upgraded to
Newton are deploying those features (maybe also noting they will be
required to upgrade to Ocata)? However, the other side of me knows that
most major production deployments are also lagging behind by a few
releases, and may only now be upgrading, or planning to upgrade, to
Mitaka since we've recently end-of-life'd the Liberty release. So asking
questions about cells v2 or the placement service is probably premature.
It might be better to ask about microversion adoption, i.e. if you're
monitoring API request traffic to your cloud, what % of compute API
requests are using a microversion > 2.1.


My vote would be to ask the following question:

Have you considered using (or already chosen) an alternative to 
OpenStack Nova for launching your software workloads? If you have, 
please list one to three reasons why you chose this alternative.


Thanks,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Feedback for upcoming user survey questionnaire

[Matt Riedemann]

We have the opportunity to again [1] ask a question in the upcoming user 
survey which will be conducted in February. We can ask one question and 
have it directed to either *users* of Nova, people *testing* nova, or 
people *interested* in using/adopting nova. Given the existing adoption 
of Nova in OpenStack deployments (98% as of October 2016) I think that 
sliding scale really only makes sense to direct a question at existing 
users of the project. It's also suggested that for projects with over 
50% adoption to make the question quantitative rather than qualitative.


We have until January 9th to submit a question. If you have any 
quantitative questions about Nova to users, please reply to this thread 
before then.


Personally I tend to be interested in feedback on recent development, so 
I'd like to ask questions about cells v2 or the placement API, i.e. they 
were optional in Newton but how many deployments that have upgraded to 
Newton are deploying those features (maybe also noting they will be 
required to upgrade to Ocata)? However, the other side of me knows that 
most major production deployments are also lagging behind by a few 
releases, and may only now be upgrading, or planning to upgrade, to 
Mitaka since we've recently end-of-life'd the Liberty release. So asking 
questions about cells v2 or the placement service is probably premature. 
It might be better to ask about microversion adoption, i.e. if you're 
monitoring API request traffic to your cloud, what % of compute API 
requests are using a microversion > 2.1.


Previous release priorities might spur some other ideas [2].

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103396.html

[2] https://specs.openstack.org/openstack/nova-specs/#priorities

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[Esra Celik]

Hi Jay, I was asking because our discussions to contribute to nova-docker 
project ran across the discussions here to retire the project :) 

Hongbin, that is exactly what I meant. Using nova-docker it deploys containers 
to physical machines, not virtual machines. 
Using Ironic driver with Magnum is a solution, but I guess every time creating 
a cluster with Magnum it will redeploy the operating system for the selected 
physical machine, which is not necessary. 
I will investigate Zun project more, thank you very much. What would you say 
for its current maturity level? 



- Orijinal Mesaj -


Kimden: "Hongbin Lu"  
Kime: "OpenStack Development Mailing List (not for usage questions)" 
 
Gönderilenler: 26 Aralık Pazartesi 2016 17:53:00 
Konu: Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker? 

I guess "extra virtualization layer" means Magnum provisions a Container 
Orchestration Engines (COE) on top of nova instances. If the nova instances are 
virtual machines, there is a "extra virtualization layer". 

I think you could consider using Magnum with Ironic driver. If the driver is 
Ironic, COEs are deployed to nova instances that are physical machines provided 
by Ironic. Zun project [1] could be another option for your use case. Zun is 
similar to nova-docker, which enables running containers on compute hosts. You 
could find a thoughtful introduction here [2]. 

[1] https://wiki.openstack.org/wiki/Zun 
[2] 
http://www.slideshare.net/hongbin034/zun-presentation-openstack-barcelona-summit
 

Best regards, 
Hongbin 

On Mon, Dec 26, 2016 at 8:23 AM, Jay Pipes < jaypi...@gmail.com > wrote: 


On 12/26/2016 08:23 AM, Esra Celik wrote: 


Hi All, 

It is very sad to hear nova-docker's retirement. Me and my team (3) are 
working for a cloud computing laboratory and we were very keen on 
working with nova-docker. 
After some research about its current state I saw these mails. Will you 
actually propose another equivalent to nova-docker or is it just the 
lack of contributors to this project? 
Some of the contributors previously advised us the magnum project 
instead of nova-docker, however it does not satisfy our needs because of 
the additional virtualization layer it needs. 
If the main problem is the lack of contributors we may participate in 
this project. 


There's never any need to ask permission to contribute to a project :) If 
nova-docker driver is something you cannot do without, feel free to contribute 
to it. 

That said, Magnum does seem to be where most of the docker-related 
contributions to the compute landscape have moved. So, it's more likely you 
will find company in that project and perhaps be able to make more effective 
contributions there. Can I ask what is the "extra virtualization layer" that 
you are referring to in Magnum? 

Best, 
-jay 


__ 
OpenStack Development Mailing List (not for usage questions) 
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 





__ 
OpenStack Development Mailing List (not for usage questions) 
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [legal-discuss] [all][tc][kolla]is it OK to modify python code in OpenStack project?

[Davanum Srinivas]

PSF is ok per (https://governance.openstack.org/tc/reference/licensing.html)
Though the overriding the _read() seems like something that could
break easily

-- dims

On Mon, Dec 26, 2016 at 12:13 PM, Michał Jastrzębski  wrote:
> Added all and tc tags, as it might affect everyone really.
>
> On 25 December 2016 at 23:04, Jeffrey Zhang  wrote:
>> Recently, Kolla project has requirement to modify[1] the python's
>> ConfigParser.py code[0].
>>
>> Python is using PSF license[3], which is GPL compatible. But OpenStack
>> is using Apache License.
>>
>> Here is the diff view[2].
>>
>> I want to make sure: is it OK to re-license ConfigParser.py? If not, what
>> the solution?
>>
>> [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py
>> [1] https://review.openstack.org/412101
>> [2]
>> https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da371/revisions?diff=split
>> [3] https://docs.python.org/3/license.html
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> ___
>> legal-discuss mailing list
>> legal-disc...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
>>
>
> ___
> legal-discuss mailing list
> legal-disc...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [legal-discuss][all][tc][kolla]is it OK to modify python code in OpenStack project?

[Michał Jastrzębski]

Added all and tc tags, as it might affect everyone really.

On 25 December 2016 at 23:04, Jeffrey Zhang  wrote:
> Recently, Kolla project has requirement to modify[1] the python's
> ConfigParser.py code[0].
>
> Python is using PSF license[3], which is GPL compatible. But OpenStack
> is using Apache License.
>
> Here is the diff view[2].
>
> I want to make sure: is it OK to re-license ConfigParser.py? If not, what
> the solution?
>
> [0] https://github.com/python/cpython/blob/2.7/Lib/ConfigParser.py
> [1] https://review.openstack.org/412101
> [2]
> https://gist.github.com/jeffrey4l/2258b276cbd038e73797cfa0952da371/revisions?diff=split
> [3] https://docs.python.org/3/license.html
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> ___
> legal-discuss mailing list
> legal-disc...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [murano] No meetings on 12.27 and 01.3 due to holidays

[Kirill Zaitsev]

Fellow murano developers, I suggest we skip the next two meetings due to
holidays =)


-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[Hongbin Lu]

I guess "extra virtualization layer" means Magnum provisions a Container
Orchestration Engines (COE) on top of nova instances. If the nova instances
are virtual machines, there is a "extra virtualization layer".

I think you could consider using Magnum with Ironic driver. If the driver
is Ironic, COEs are deployed to nova instances that are physical machines
provided by Ironic. Zun project [1] could be another option for your use
case. Zun is similar to nova-docker, which enables running containers on
compute hosts. You could find a thoughtful introduction here [2].

[1] https://wiki.openstack.org/wiki/Zun
[2]
http://www.slideshare.net/hongbin034/zun-presentation-openstack-barcelona-summit

Best regards,
Hongbin

On Mon, Dec 26, 2016 at 8:23 AM, Jay Pipes  wrote:

> On 12/26/2016 08:23 AM, Esra Celik wrote:
>
>> Hi All,
>>
>> It is very sad to hear nova-docker's retirement. Me and my team (3) are
>> working for a cloud computing laboratory and we were very keen on
>> working with nova-docker.
>> After some research about its current state I saw these mails. Will you
>> actually propose another equivalent to nova-docker or is it just the
>> lack of contributors to this project?
>> Some of the contributors previously advised us the magnum project
>> instead of nova-docker, however it does not satisfy our needs because of
>> the additional virtualization layer it needs.
>> If the main problem is the lack of contributors we may participate in
>> this project.
>>
>
> There's never any need to ask permission to contribute to a project :) If
> nova-docker driver is something you cannot do without, feel free to
> contribute to it.
>
> That said, Magnum does seem to be where most of the docker-related
> contributions to the compute landscape have moved. So, it's more likely you
> will find company in that project and perhaps be able to make more
> effective contributions there. Can I ask what is the "extra virtualization
> layer" that you are referring to in Magnum?
>
> Best,
> -jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Using neutron lib plugin constants

[Gary Kotton]

Hi,
Please note the following two patches:

1.   https://review.openstack.org/414902 - use CORE from neutron lib

2.   https://review.openstack.org/394164 - use L3 (previous known as 
L3_ROUTER_NAT)
Please note that the above will be removed from 
neutron/plugins/common/constants.py
 and neutron-lib will be used.

For the core change I have posted:

1.   VPNaaS - https://review.openstack.org/#/c/414915/

For the L3 change things are a little more complicated 
(http://codesearch.openstack.org/?q=L3_ROUTER_NAT=nope==):

1.   networking-cisco – https://review.openstack.org/414977

2.  group-based-policy – https://review.openstack.org/414976

3.   big switch - https://review.openstack.org/414956

4.   brocade - https://review.openstack.org/414960

5.   dragonflow - https://review.openstack.org/414970

6.  networking-huawei - https://review.openstack.org/414971

7.  networking-odl = https://review.openstack.org/414972

8.  astara-neutron - https://review.openstack.org/414973

9.  networking-arista - https://review.openstack.org/414974

10.  networking-fortinet - https://review.openstack.org/414980

11.  networking-midonet - https://review.openstack.org/414981

12.  networking-nec - https://review.openstack.org/414982

13.  networking-onos - https://review.openstack.org/414983

Please note that I have not put a ‘Depends-On’ as these patches can and should 
land prior.
Thanks and happy new year
Gary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[Jay Pipes]

On 12/26/2016 08:23 AM, Esra Celik wrote:

Hi All,

It is very sad to hear nova-docker's retirement. Me and my team (3) are
working for a cloud computing laboratory and we were very keen on
working with nova-docker.
After some research about its current state I saw these mails. Will you
actually propose another equivalent to nova-docker or is it just the
lack of contributors to this project?
Some of the contributors previously advised us the magnum project
instead of nova-docker, however it does not satisfy our needs because of
the additional virtualization layer it needs.
If the main problem is the lack of contributors we may participate in
this project.


There's never any need to ask permission to contribute to a project :) 
If nova-docker driver is something you cannot do without, feel free to 
contribute to it.


That said, Magnum does seem to be where most of the docker-related 
contributions to the compute landscape have moved. So, it's more likely 
you will find company in that project and perhaps be able to make more 
effective contributions there. Can I ask what is the "extra 
virtualization layer" that you are referring to in Magnum?


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[Esra Celik]

Hi All, 

It is very sad to hear nova-docker's retirement. Me and my team (3) are working 
for a cloud computing laboratory and we were very keen on working with 
nova-docker. 
After some research about its current state I saw these mails. Will you 
actually propose another equivalent to nova-docker or is it just the lack of 
contributors to this project? 
Some of the contributors previously advised us the magnum project instead of 
nova-docker, however it does not satisfy our needs because of the additional 
virtualization layer it needs. 
If the main problem is the lack of contributors we may participate in this 
project. 

Any o pinions? 

ecelik 

- Orijinal Mesaj -

> Kimden: "Matt Riedemann" 
> Kime: openstack-dev@lists.openstack.org
> Gönderilenler: 23 Aralık Cuma 2016 6:30:53
> Konu: Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

> On 12/22/2016 8:26 PM, Tony Breeds wrote:
> > Hi All,
> > I know this comes up from time to time, but as the subject says, is it time
> > to retire nova-docker.
> >
> > The nova-docker has lagged behind the last 6 months of nova development and
> > no
> > longer passes simple CI unit tests. There are open patches to at least get
> > the
> > unit tests to pass[1] but if the current core team no longer has time (no
> > offence intended) then perhaps we should just archive it.
> >
> > Thoughts?
> >
> > Yours Tony.
> > [1]
> > https://review.openstack.org/#/q/status:open+project:openstack/nova-docker+branch:master+topic:fixes_for_master
> >
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

> +1 for what it's worth.

> People show up in the nova channel in IRC from time to time (maybe once
> or twice per year) asking about the state of the driver and I send them
> to the nova-docker IRC channel, but also explain it's not really maintained.

> I know people are running it and hacking on it outside of the community
> repo, which is fine, and if someone doing that wanted to stand up and
> say they wanted to own the repo and be the core team I'd be fine with
> that too, but so far no one has done that in the last few years. If
> you're already maintaining it outside of the community I don't know why
> you wouldn't just do that development in the open, and maybe get a free
> bug fix at times from another contributor, but I suppose people have
> their reasons (secret sauce and all that). So meh.

> --

> Thanks,

> Matt Riedemann

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [mistral] no team meeting - 12/26/2016

[Renat Akhmerov]

Hi,

I guess it doesn’t make a lot of sense to hold a meeting today, most people are 
on holidays.

Merry Christmas and Happy New Year! I wish you all the best!

See you in the New Year :)

Renat Akhmerov
@Nokia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa][ptg] session idea for Pike cycle

[Ken'ichi Ohmichi]

Hi QA-team,

We will have the first PTG[1] next Feb and it is nice to get session ideas now.
I am looking forward to seeing new ideas and discussing them together
as the community.
The etherpad is https://etherpad.openstack.org/p/qa-ptg-pike
Please write your ideas down on that if you have.
Thanks for your contributions and see you in Atlanta.


Thanks
Ken Ohmichi

---
[1]: https://www.openstack.org/ptg/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Telemetry] Asking a question to our users

[Julien Danjou]

Hi folks,

The foundation is offering the opportunity to ask a question to users:

  "I wanted to offer you the opportunity to ask a question on the
  upcoming User Survey, which launches on or before Feb. 1. Each PTL of
  a project with significant adoption can submit one question. You can
  decide which audience to serve the question to - those who are USING,
  TESTING, or INTERESTED in your project (or some combination of these)."

Would anyone have an interesting idea/question to ask our beloved users?

Cheers,
-- 
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] early prototype for HW VNC console interface

[Pavlo Shchelokovskyy]

Hi all,

While the work on generic graphical console [0] has somewhat stalled, I
went ahead and created a prototype of graphical console interface for some
specific Dell servers of interest for me (iDRAC8).

This of course is too far away from any production use, but still with a
couple of hacks I was able to get a graphical console in horizon Dashboard
connected and operating with a nova instance deployed onto ironic node :)

I've posted my experiences in my blog [1], hopefully you'll find it it
interesting or at least amusing. Questions and comments are very welcome.

[0] https://review.openstack.org/#/c/306074/ 
[1] *http://pshchelo.github.io/vnc-in-ironic.html
*

Cheers and happy holidays,
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev