Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Chen CH Ji]

Yes, fully understand this ,thanks for sharing!

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Jim Rollenhagen 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/20/2018 10:13 PM
Subject:Re: [openstack-dev] [Nova] z/VM introducing a new config
driveformat



On Fri, Apr 20, 2018 at 4:02 AM, Chen CH Ji  wrote:
  Thanks a lot for your sharing, that's good info, just curious why [1]
  need zip and base64 encode if my understand is correct
  I was told nova need format should be pure vfat or iso9660, I assume it's
  because actually the config drive itself is making by iso by default
  then wrap a zip/base64 format ... thanks



We only gzip and base64 to send it to the ironic API. It is decoded and
unzipped before writing it to disk, so it is a pure iso9660 on the disk.

// jim
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=4L-KwemnBkUdTMyGA_BviipEqJ7MKNGlKFMKH6J6iaM=S52V2lLNK1Mh7rprSl-edF3Q2M4m3qEXcWd3jTW8Y9g=



__
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] [tc] campaign question related to new projects

[Sean McGinnis]

> 
> We are discussing adding at least one new project this cycle, and
> the specific case of Adjutant has brought up questions about the
> criteria we use for evaluating new projects when they apply to
> become official.  Although the current system does include some
> well-defined requirements [1], it was also designed to rely on TC
> members to use their judgement in some other areas, to account for
> changing circumstances over the life of the project and to reflect
> the position that governance is not something we can automate away.
> 

Good question to get the conversation going Doug. This is an interesting point
that I think will require some longer term discussions.

It would be nice if we can narrow this down to a more defined decision tree,
but I also think it may be too difficult to get to the point where it is
something that can be that black and white. For better or worse, I do think
there is some subjective evaluation that is required for each of these so far.

I think following our four opens is the basis for most decisions. They need to
be developing projects in an open way, and open to community involvement with
the implementation and direction of the project, as a basic starting point. If
they are not willing to follow these basic principles then I think it is an
easy decision to not go any further from there.

We do care about diversity in contributors. I think it is very important for
the long term health of a project to have multiple interests involved. But I do
not consider this a bar to entry. I think it is perfectly OK for a new (but
open) project to come in with the majority of the work coming from one vendor.
As long as they are open and willing to get others involved in the development
of the project, then it is good. And at least sometimes, starting off is
sometimes better with one perspective driving things toward a focused solution.

I think one of the important things is if it fits in to furthering what is
"OpenStack", as far as whether it is a service or functionality that is needed
and useful for those running an OpenStack cloud. This is one of the parts that
may be more on the subjective side. We need to see that adding the new project
in question will enhance the use or operation of an OpenStack environment.

There is the question about overlap with existing projects. While I think it's
true that a new project can come along that meets a need in a better way than
an existing solution, I think that bar needs so be raised a lot higher. I
personally would much rather see resources joining together on an existing
solution than a bunch of resources used to come up with a competing solution.
Even with a less than ideal solution, there is a lot that is learned from the
process that can be fed into and combined with new ideas to create a better
solution than just having a new replacement.

There's probably a lot more that can be said about all of this, but that's my
initial take. Looking forward to seeing what everyone else has to say and
learning from how we are the same and how we are different on this topic.

Sean

__
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] [kolla] kolla September ptg survey

[Surya Singh]

Hello Jeffrey,

Filled the form. Yes, it's always good time to gather and discuss
about the next roadmap at PTG. As It was great at Dublin PTG for Kolla
despite snow storm.
Hope I would be able to travel.

---spsurya


On Mon, Apr 23, 2018 at 10:33 AM, Jeffrey Zhang  wrote:
> Hi kollars
>
> The next PTG will be held at Denver Colorado on September 10-14, 2018[0]. We
> have to decide whether Kolla will participate. I personally think ptg is a
> great time for the team to gather together to resolve issues and make next
> roadmap. But it is not that easy for every to travel.
>
> So please take minutes to fill this form[1] before May 2nd. Then we cloud
> decide whether we should book a root at ptg.
>
> [0] https://www.openstack.org/ptg
> [1] https://goo.gl/forms/9ZHUw4GBUvggNl643
>
>
> --
> 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 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] [kolla] kolla September ptg survey

[Jeffrey Zhang]

​​
Hi kollars

The next PTG will be held at Denver Colorado on September 10-14, 2018[0].
We have to decide whether Kolla will participate. I personally think ptg is
a great time for the team to gather together to resolve issues and make
next roadmap. But it is not that easy for every to travel.

So please take minutes to fill this form[1] before May 2nd. Then we cloud
decide whether we should book a root at ptg.

[0] https://www.openstack.org/ptg
[1] https://goo.gl/forms/9ZHUw4GBUvggNl643


-- 
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

Re: [openstack-dev] [tc] campaign question related to new projects

[Thierry Carrez]

Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> We are discussing adding at least one new project this cycle, and
> the specific case of Adjutant has brought up questions about the
> criteria we use for evaluating new projects when they apply to
> become official.  Although the current system does include some
> well-defined requirements [1], it was also designed to rely on TC
> members to use their judgement in some other areas, to account for
> changing circumstances over the life of the project and to reflect
> the position that governance is not something we can automate away.
> 
> Without letting the conversation devolve too much into a discussion
> of Adjutant's case, please talk a little about how you would evaluate
> a project's application in general.  What sorts of things do you
> consider when deciding whether a project "aligns with the OpenStack
> Mission," for example?

Thanks for getting the discussion started, Doug.

We have two main criteria in the requirements. The "follows the
OpenStack way" one, which I call the culture fit, and the "aligns with
the OpenStack mission" one, which I call the product fit. In both cases
there is room for interpretation and for personal differences in
appreciation.

For the culture fit, while in most cases its straightforward (as the
project is born out of our existing community members), it is sometimes
much more blurry. When the group behind the new project is sufficiently
disjoint from our existing team members, you are judging a future
promise to behave in "the OpenStack way". In those cases it's really an
opportunity to reach out and explain how and why we do things the way we
do them, the principles behind our community norms. In the end it's a
leap of faith. The line I personally stand on is the willingness to
openly collaborate. If the new group is a closed group that has no
interest in including new people and wants to retain "control" over the
project, and is only interested in the marketing boost of being a part
of "OpenStack", then it should really be denied. We provide a space for
open collaboration, not for openwashing projects.

For the product fit, there is also a lot of room for interpretation. For
me it boils down to whether "OpenStack" (the product) is better with
that project "in" rather than with that project "out". Sometimes it's an
easy sell: if a group wants to collaborate on packaging OpenStack for a
certain format/distro/deployment tool, it's clearly a win. In that case
more is always better. But in most cases it's not as straightforward.
There is always tension between added functionality on one side, and
complexity / dilution / confusion on the other. Every "service" project
we add makes OpenStack more complex to explain, cross-project work more
difficult and interoperability incrementally harder. Whatever is added
has to be damn interesting to counterbalance that. The same goes for
competitive / alternative projects: in some cases the net result is a
win (different approaches to monitoring), while in some cases the net
result would be a loss (a Keystone alternative that would make everyone
else's life more miserable).

In summary while the rules are precise, the way we interpret them can
still be varied. That is why this discussion is useful: comparing notes
on how we answer that difficult question, understanding where everyone
stands, helps us converge to a general consensus of the goals we are
trying to achieve when defining "OpenStack" scope, even if we disagree
on the particulars.

-- 
Thierry Carrez (ttx)

__
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] [tc] campaign question related to new projects

[Rico Lin]

Thanks, Doug, for raising this campaign question


Here are my answers:


***How you would evaluate a project's application in general

First I would work through the requirements ([1]) to evaluate projects.
Since most of the requirements are specific enough. And here's more
important part, to leave evaluate logs or comments for projects which we
considered but didn't reach some requirements. It's very important to guide
projects to cross over requirements (and remember, a `-1` only means we
trying to help).

Then, I work on questions, like:

`How many user are interesting to/needs the functionality that service
provided?`

`How active is this project and how's the diversity of contributors?`

`Is this project required cross communities/projects cooperation? If yes,
how's the development workflows  are working between communities/projects?`

And last but is one of the most important questions,

`Is this service aligns with the OpenStack Mission`? (and let's jump to
next question to answer this part)



**What sorts of things do you consider when deciding whether a project
"aligns with the OpenStack Mission," for example?*

I would consider things like:

`Is the project's functionality complete the OpenStack infrastructure map?`

Asking from user requirement and functionality point of view, `how's the
project(services) will make OpenStack better infrastructure for
user/operators?` and `how's this functionality provide a better life for
OpenStack developers?`

`Is the project provides better integration point between communities`

To build a better infrastructure, IMO it's also important to ask if a
project (service) really help on integration with other communities like
Kubernetes, OPNFV, CEPH, etc. I think to keep us as an active
infrastructure to solutions is part of our mission too.

`Is it providing functionality which we can integrate with current projects
or SIG instead?`

In short, we should be gathering our development energy, to really achieve
the jobs which is exactly why we spend times on trying to find official
projects and said this is part of our mission to work on. So when new
projects jump out, it's really important to discuss cross-project `is it
suitable for projects integrated and join force on specific functionality?`
(to do this while evaluating a project instead of when it's creating might
not be the best time to said `please integrate or join forces with other
teams together`(not even with a smiling face), but it's never too late for
a non-official/incubating project to consider about this). I really don't
like to to see any project get higher chances to die just because
developers chance their developing focus. It's happening when projects are
all willing to do the functionality, but no communication between(some
cases, not even now other projects exists), and new/old projects dead, then
TC needs to spend the time to pick those projects out. So IMO, it's worth
to spend times to investigate on whether projects can be joined. Or ideally
to put a resolution said, it's project's obligation to help on this, and
help other join force to be part of the team.

`Can projects provide cross-project gating?`

Do think if it's possible, we should consider this when asking if a service
aligns with our mission because not breaking rest of infrastructure is part
of the definition of `to build`. And providing cross-project gate jobs
seems like a way to go. To stable the integration between projects and
prevent released a failed feature when other services trying to work on new
ways and provide no guideline, ML, or solution, just only leave words like
`this is not part of our function to fix`.



And finally,

If we can answer all above questions, try to put in with the more accurate
number (like from user survey), and provides communications it needs, will
definitely help in finding next official projects.

Also, when the evaluation is done, we should also evaluate the how's these
evaluation processes, how's guideline working for us? and which questions
above doesn't make any sense?.


[1]
https://governance.openstack.org/tc/reference/new-projects-requirements.html


May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
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